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] der...@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] der...@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] j...@php.net
Derick, any comments?
------------------------------------------------------------------------
[2008-07-28 22:46:30] j...@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
