|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25825 Windows PHP always returns UTC time and BST as the timezone
Submitted: 2003-10-10 14:30 UTC Modified: 2003-10-14 20:24 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: pennington at rhodes dot edu Assigned: wez (profile)
Status: Closed Package: Date/time related
PHP Version: 4.3.3 OS: Windows 2000
Private report: No CVE-ID: None
 [2003-10-10 14:30 UTC] pennington at rhodes dot edu
The Windows version of PHP 4.3.3 does not return the system's time when the date() command is used. It only returns UTC time and "BST" as the timezone, even when the Windows server is set to use local time and reports as such in the Date/Time control panel.

Please note that this is different than bug #23467 because the time being reported is wrong (UTC rather than the local CST), in addition to the wrong "BST" timezone.

Reproduce code:
echo date("D M j G:i:s T Y");

Expected result:
Fri Oct 10 13:28:58 CST 2003

Actual result:
Fri Oct 10 18:28:58 BST 2003


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-10-12 19:46 UTC]
This is not different to bug #23467

 [2003-10-13 09:52 UTC] pennington at rhodes dot edu wanted to know "Which SAPI are you running? CGI? ISAPI? Apache? Something else?"

I'm running ISAPI.

I fail to see how this bug is identical to bug #23467, because I am getting an incorrect offset of time from GMT in addition to the incorrect time zone appearing. Unless, of course, time in general is screwed up for PHP on Win32...
 [2003-10-13 12:14 UTC]
Do you get the same problem running CGI?

 [2003-10-13 17:53 UTC] pennington at rhodes dot edu
Interestingly, when testing to see if this UTC display of time would happen for PHP installed as a CGI (couldn't reproduce with Apache2 or IIS5 as a CGI), I noticed that the UTC time problem does not show up right away with PHP installed as ISAPI on IIS5. Rather, when you stop the IIS service and then start it again, for a period of time, the correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server averaging a few users at a time), the time switches to UTC and does not go back.

If you stop IIS and then start it again, the time goes back to the correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because I've been having trouble getting the Windows 2000 Server, which uses PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as setting cgi.force_redirect = 0 and changing the app mapping configuration to point to the php.exe and not the php4isapi.dll but I'm not having any luck (get "not authorized to view this page" on php scripts). This method works fine on the Win2K workstation. Anyway, this is not related to the UTC time issue...
 [2003-10-13 18:41 UTC]
Do any of your scripts use setlocale() or other similar function to manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default.
 [2003-10-14 10:29 UTC] pennington at rhodes dot edu
I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that manipulate the locale?
 [2003-10-14 12:15 UTC]
The only other way to manipulate locale is via putenv(), which would change LC_* environment variable.
 [2003-10-14 14:22 UTC] pennington at rhodes dot edu
Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we are running does use putenv() in the following function:


     * Is the given date/time in DST for this time zone
     * Attempts to determine if a given Date object represents a date/time
     * that is in DST for this time zone.  WARNINGS: this basically attempts to
     * "trick" the system into telling us if we're in DST for a given time zone.
     * This uses putenv() which may not work in safe mode, and relies on unix time
     * which is only valid for dates from 1970 to ~2038.  This relies on the
     * underlying OS calls, so it may not work on Windows or on a system where
     * zoneinfo is not installed or configured properly.
     * @access public
     * @param object Date $date the date/time to test
     * @return boolean true if this date is in DST for this time zone
    function inDaylightTime($date)
        $env_tz = "";
        if(getenv("TZ")) {
            $env_tz = getenv("TZ");
        $ltime = localtime($date->getTime(), true);
        return $ltime['tm_isdst'];


Are you saying that this could change the environment variable for timezone for the entire server for good (at least until IIS5 is restarted) once this code is executed? And this would affect pages that don't even include the function above?
 [2003-10-14 18:37 UTC]
Yes; that is what is happening.
I'll look into having PHP reset to the system default locale at the start of each request.
 [2003-10-14 20:24 UTC]
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.

The problem was that putenv("TZ=...") would call tzset() in order to update the libc with the timezone information for the time related functions, but PHP would not call tzset() again when the environment was reset.

I've checked in a fix for this problem, which should hopefully make things better.

However, a word of warning:
The environmental variables are process-wide, so changing
them in a threaded environment like ISAPI may cause some
gotchas in high-concurrency scenarios (eg: two threads
might be playing with the same env var at the same time).

I'm marking this report as closed as the next snapshots
will contain the fix.  If the problem is still present
in those, please reopen this report.

 [2014-05-11 12:09 UTC] anshuman_chatterjee14 at yahoo dot com
The Problem is too common as PHP data time function calls GMT time not our specific time zone time....\

i too faced the problem.. there is a simple answer to it...
strtotime('+ 5 hour 30 minute') // your time zone mine id IST = GMT + 5:30
instead of 

 so to obtain a full time you do the following.

date("l-jS-F-Y g:i:s A", strtotime('+ 5 hour 30 minute'))

= Sunday-11th-May-2014 5:32:30 PM 
as answer.....
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 22 19:01:31 2024 UTC