I have the same problem.

 The "localtime" argument passed to the php_format_date() function
was changed from 1 to 0 between 5.3.8 and 5.3.9.

 Did it cause the problem?


In /[svn]/php/php-src/branches/PHP_5_3/main/main.c
*revision 319750, line 602:
    error_time_str = php_format_date("d-M-Y H:i:s", 11, error_time, 1 TSRMLS_CC);

*revision 319823, line 602:
    error_time_str = php_format_date("d-M-Y H:i:s e", 13, error_time, 0 TSRMLS_CC);

I have the same issue running PHP 5.3.9 on Windows IIS 7.5

Hi!

We had to change this in order to prevent crashes (like in https://bugs.php.net/bug.php?id=60373). I'll check whether there is a better way to fix it.

cheers,
Derick

hi,

I am having the same issue , i am having php 5.3.9 on "CENTOS 6.2 x86_64"


Deepak

Same problem, php 5.3.9; FreeBSD 8.0 & 9.0

Same problem for me on IIS 7, Windows 2008 Webserver, PHP 5.3.10

Same. PHP 5.3.10 CentOS 5

I have same problem

php -v
PHP 5.3.10 (cli) (built: Feb  4 2012 07:36:51)

CentOS release 6.2 (Final)

Same:

PHP 5.3.10 with Suhosin-Patch (cli) (built: Mar 14 2012 11:01:12) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator

Is there any path? PHP 5.3.10

Is there any progress with solution for this bug?

The merit which makes this message UTC fixation is not known. 
How about changing in this way? 

---- in main/main.c
-error_time_str = php_format_date("d-M-Y H:i:s e", 13, error_time, 0 TSRMLS_CC);
+error_time_str = php_format_date("d-M-Y H:i:s T", 13, error_time, 1 TSRMLS_CC);
----

---- output(date.timezone='Asia/Tokyo')
[06-Jun-2012 13:54:12 JST] foo
----

Present also in PHP 5.3.13


CentOS release 5.7 (Final)
Linux blah 2.6.18-274.18.1.el5PAE #1 SMP Thu Feb 9 13:25:50 EST 2012 i686 i686 i386 GNU/Linux


PHP 5.3.13 (cli) (built: Jun 13 2012 14:53:50) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

same problem in PHP 5.3.14 and 5.4.4
my OS is Windows XP

Same, PHP 5.3.14 Debian Squeeze

Why is it neglected? 
The cause of this bug is specification change by the wrong bug fix method.

Is someone working on this? It's quite an annoying bug.

I'm using PHP 5.3.13 on Windows, and I'm also experiencing this annoying bug.  
Please, please fix it.  I liked when it used the server timezone settings.

Also having this issue on 5.4.1 running on Windows 2008 R2.  Very annoying!  Wish I never upgraded us from 5.3.8!!!

seems introduced after the fix of: https://bugs.php.net/bug.php?id=60373

laruence:
It will be a peculiar problem in ZTS. 
I think that it does not become a reason fixed to UTC in all?

yes，I have attached a patch, will
commit it later, I am not able to do a whole test now:)

Hi,

I don't think the existing behaviour (string format) should be changed, for most users.  I expect there will be many shell scripts that will break slightly because the TZ is now written into the error_time_str.   I have patched my build to only add the TZ to the string if expected behaviour is different (ie logged time is in UTC).

I revert to original behaviour on initially setting error_time_str (localtime = 1), and then add an '#ifdef ZTS' to set it with localtime = 1 and include 'e' in the format string.

I can add this patch file ?

cheers,

sorry, a typo above.  I set localtime to 0 (zero) ifdev ZTS

cheers,

@junk I think the format of output should be consistent. which means either all 
include the 'e', or all don't.

The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Hi,
this "bug" is fixed ?
which version of PHP will this fix be committed in ?
Thank you.

hey, committed to 5.3 5.4 branches, will fixed in next release, thanks

Should hopefully be released in 5.3.18, since 5.3.17 was released just a few days 
before the patch was committed (13-Sep-2012 vs 23-Sep-2012). Glad to hear this 
has been resolved, thanks!

i do not see anything fixed 
errorlog still contains the timezone

PHP 5.3.21 as also 5.4.11

[28-Jan-2013 16:22:38 Europe/Vienna] PHP Parse error:  syntax error, unexpected end of file in Command line code on line 1

the sysadmin knows his timezone well enough...................

Don't see the fix in Debians testing packages (specifically 5.4.4), still seeing the UTC time instead of the local time:

# apt-cache policy php5
php5:
  Instalados: 5.4.4-13
  Candidato:  5.4.4-13
  Tabla de versión:
     5.5.0~alpha4-1 0
         40 http://ftp.de.debian.org/debian/ experimental/main i386 Packages
 *** 5.4.4-13 0
        500 http://ftp.de.debian.org/debian/ testing/main i386 Packages
         50 http://ftp.de.debian.org/debian/ unstable/main i386 Packages
        100 /var/lib/dpkg/status
     5.3.3-7+squeeze14 0
        500 http://security.debian.org/ squeeze/updates/main i386 Packages
        500 http://ftp.de.debian.org/debian/ stable/main i386 Packages

From the log file:

[25-Feb-2013 11:05:46 UTC] PHP Deprecated:  Assigning the return value of new by reference is deprecated in /usr/share/php/MDB2.php on line 390

I can confirm this has indeed been patched (Confirmed for v5.3.22)

BEFORE:
[04-Mar-2013 00:39:07 UTC] PHP Warning:

AFTER:
[06-Mar-2013 06:27:16 America/Denver] PHP Warning:

I can confirm that the problem persist on Debian testing

# apt-cache policy php5
php5:
  Installed: 5.4.4-14
  Candidate: 5.4.4-14
  Version table:
 *** 5.4.4-14 0
        500 http://mirrors.gandi.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

# tail -1 error.log
[07-Apr-2013 11:30:56 UTC] PHP Strict Standards ...

Hi!

Bug persist on Debian GNU/Linux 7.0 and php 5.4.4-14+deb7u7:

[01-Mar-2014 13:24:32 UTC] creating new js file public://languages/ru_NBsyVj40mmTmz4zs-DHETmx_j2Ja7-xOshWB5Uwho1M.js


$ LC_ALL=POSIX date
Sat Mar  1 17:28:31 MSK 2014

Any glue why is hasn't been fixed yet?