Bug #45191 [Com]: error_log ignores date.timezone php.ini val when setting logging timestamps

Edit report at https://bugs.php.net/bug.php?id=45191&edit=1 ID: 45191 Comment by: wadkar at gmail dot com Reported by: info at organicdata dot co dot za Summary: error_log ignores date.timezone php.ini val when setting logging timestamps Status: Closed Type: Bug Package: Date/time related Operating System: Centos el5 PHP Version: 5.2CVS-2008-06-05 (snap) Assigned To: derick Block user comment: N Private report: N New Comment: This bug may still be a problem for someone, here are the details : # php -v PHP 5.3.8 (cli) (built: Dec 1 2011 12:23:50) The problem is with the OS this time= CentOS 5+OpenVZ with IUS repo. The host machine (with the OpenVZ kernel) has no problems # uname -a Linux vz-node2 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux # echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r 'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date [30-Jan-2012 14:38:56] PHP Notice: Use of undefined constant SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in Command line code on line 1 Mon Jan 30 14:38:56 IST 2012 The same code snippet, however, when run on a VM gives # uname -a Linux container1 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux # echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r 'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date [30-Jan-2012 09:10:05 UTC] PHP Notice: Use of undefined constant SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in Command line code on line 1 Mon Jan 30 14:40:05 IST 2012 The internal TZ settings are respected though: # php -i | grep timezone Default timezone => Asia/Calcutta date.timezone => Asia/Calcutta => Asia/Calcutta # php -r 'echo date_default_timezone_get(), PHP_EOL; $d = new DateTime(); echo $d->format(DATE_RFC822), PHP_EOL;' && date Asia/Calcutta Mon, 30 Jan 12 14:49:17 +0530 Mon Jan 30 14:49:17 IST 2012 I am not sure if this is the bug with PHP or with virtualized environment. I just wanted to comment/report my observation. I was worried for a moment that my CLI scripts would fail to respect the TZ settings, but that is not the case. Thanks -Sudarshan Wadkar Previous Comments: ------------------------------------------------------------------------ [2009-05-03 19:09:31] derick@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2008-07-29 06:46:39] derick@php.net It should be switched from strftime() to php_format_date(). This is not an issue with the Date/Time functionality though, but with the syslog one. ------------------------------------------------------------------------ [2008-07-28 22:47:26] jani@php.net Derick, any comments? ------------------------------------------------------------------------ [2008-07-28 22:46:30] jani@php.net Actually error_log="somefile.log" does not use any syslog stuff to write the entries in it. This is the line from main.c:490 which gets executed if error_log != syslog: strftime(error_time_str, sizeof(error_time_str), "%d-%b-%Y %H:%M:%S", php_localtime_r(&error_time, &tmbuf)); There are 2 problems here: [a] it's using locale sensitive %b modifier [b] It doesn't care about date.timezone. Solutions: [a] IMO it should use this pattern instead: "%Y-%m-%d %H:%M:%S" (f.e. lighttpd uses this for it's error_log entries :) [b] I don't know how to safely achieve the above mentioned issues with date.timezone vs. system timezone. Might be better leave this as is.. ------------------------------------------------------------------------ [2008-07-15 17:05:49] info at organicdata dot co dot za Thanks very much for the feedback - I understand that my "bug" interpretation may have been wrong. My concern is really a result of a combination of the following: 1. the PHP recommendations I've seen is that you don't rely on system time zone and set the time zone explicitly in PHP 2. I want to have a single central logging file containing all system errors 3. The custom error handling routine I use does not catch all errors that PHP can throw, some are only captured by the internal error handler used by setting log_errors=On Because of 3, the only way I can achieve 2 that I can see is to set the output file in my custom error handler to be the same as the value set in the inifile parameter error_log. This means that the errors I trap are then inserted into the same file as the ones I am unable to trap due to the limitation of 3 and they occur in a sensible sequence. As per your reply however, the only way for me to ensure that the errors written to the file by my custom error handler have meaningful timestamps relative to the ones written as a result of the log_errors=On parameter means that i have to set my PHP explicit timezone to the same as that of the server. ...which means that I'm setting the value on the server and again in PHP and that if there is some change in the server timezone for whatever reason at a later stage, my log file will become "a mess" of inconsistent timestamps (depending on whether the error written to the file was as a result of my custom error handling routine or whether handled by the internal error logging. ...which in turn from my perspective means that it is in fact dangerous to explicitly set the PHP internal timezone and actually safer to allow everything to rely only on the system timezone - at least this way I can guarantee consistency in the timestamps of the errors written to the log file well that's the way I see it anyway - not sure whether I'm missing something big here thanks again for the feedback ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=45191 -- Edit this bug report at https://bugs.php.net/bug.php?id=45191&edit=1