ID:               33082
 Updated by:       [EMAIL PROTECTED]
 Reported By:      benjamin dot rich at gmail dot com
 Status:           Bogus
 Bug Type:         Date/time related
 Operating System: Linux
 PHP Version:      4.3.10
 New Comment:

Careful with that.  Places on a half-hour timezone would show up as
0530, for example.  Dividing by 100 is not going to be correct for
those.


Previous Comments:
------------------------------------------------------------------------

[2005-05-21 04:21:55] benjamin dot rich at gmail dot com

Sorry, discovered this entire 2 day long hellride is not due to a php
bug but, of course, my own stupidity =P

I discovered I was incorrectly converting dates to GMT by making
date("O") the server timezone, when it should have been date("O")/100.

------------------------------------------------------------------------

[2005-05-21 04:06:00] benjamin dot rich at gmail dot com

this problem also occurs with timestamps generated from strtotime:


<?PHP
                echo "it is " . date("r  I  @B") . " Local Time<br />\n";
        echo "and " . gmdate("r  I  @B") ." GMT<br />\n";
                echo "" . date("@B  I") . " net time as of now<br />\n";

        $timestamp = strtotime(date("r"));

        
        echo "net time from current local timestamp (not local clock)
is: " . date("r @B", $timestamp) . "<br /n>";
        echo "and getting the timestamp from mktime(11,06,10,5,21,2005)
which should give @087 gives " . date("r @B",
mktime(11,06,10,5,21,2005)) . "<br />\n";
        echo "and getting the timestamp from strtotime(\"21 May 2005
11:06:10am\") which should give @087 gives " . date("r @B",
strtotime("21 May 2005 11:06:10am")) . "<br />\n";

?>

see http://cracksmokingducks.com/time.php

------------------------------------------------------------------------

[2005-05-21 03:39:08] benjamin dot rich at gmail dot com

FINAL CONCLUSION:

formatting a date with date(), using a timestamp provided by mktime(),
will always show the correct date and time - BUT *net time will only be
accurate if your server's local time is gmt+10*

By running my time.php script on my local webserver (php 4.3.11) under
different timezones, I've found there'll always be a discrepency of, at
maximum, 10hours, in net time, unless your local timezone is AEST/EST,
gmt+10.

This also happens on my server, where local time is gmt+0 - the net
time produced from a date() formatted mktime() timestamp is always
10hours ahead.

therefore, I don't know how or why, but mktime() timestamps throw off
date() and causes it to imagine the meridian is gmt+10, not gmt+0.

------------------------------------------------------------------------

[2005-05-21 03:23:16] benjamin dot rich at gmail dot com

problem somewhat solved through experimentation.

date() is not the problem - timestamps generated by mktime() are.

Here is some code to show this:

<?PHP

                echo "it is " . date("r  I  @B") . " Local Time<br />\n";
        echo "and " . gmdate("r  I  @B") ." GMT<br />\n";
                echo "" . date("@B  I") . " net time as of now<br />\n";

        $timestamp = strtotime(date("r"));

        
        echo "net time from current local timestamp (not local clock)
is: " . date("r @B", $timestamp) . "<br /n>";
        echo "and getting the timestamp from mktime(11,06,10,5,21,2005)
which should give @087 gives " . date("r B", mktime(11,06,10,5,21,2005))
. "<br />\n";

?>

on a server with a local time of gmt+10, all dates come out with the
correct net time.

on a server where the local time is set to gmt+0, all dates come out
with the correct date time except the one who's timestamp was generated
by mktime(). In this instance, the date/time that are produced are
*correct*, but the net-time produced *incorrect* - it is @504 instead
of the correct @087, which means the net time is exactly 10hours ahead
of what it should be.

given that, in this instance, the server doesn't know that my local
timezone is gmt+10 (since the server timezone is gmt+0 and I didn't
write anything into the code to account for my timezone), something
strange is happening between mktime() and date(). mktime() generates
the correct timestamp because we see the date/time are correct for the
input; but date() formats the timestamp into net-time incorrectly; BUT
*does not do this when the timestamp is returned by time() or other
functions*.

------------------------------------------------------------------------

[2005-05-21 03:00:45] benjamin dot rich at gmail dot com

update - it seems that, given a timestamp, date() will assume it is in
local time. Therefore, on a server with timezone gmt-4, when getting
the net time for a date with timezone gmt+10, you need to do the
following:

net time = local timezone - timestamp timezone - 1

the part on the end is a conundrum. i was assuming date() was
calculating the diff between local timezone and BMT, but it seems it's
just assuming your given timezone is in local server time but then
*still adding 1 hour*.

so, if your timestamp is gmt+10, the resulting net time will be 10hours
- server timezone + 1 hours out. if you convert the timestamp to gmt,
the net time will be 0hours - server timezone + 1 hours out.

So essentially, date() is doing nothing wrong except adding an hour.
why?

net time works off BMT, and BMT works off Central European Wintertime.
Does this timezone have daylight saving which is transparently being
added somewhere? This would explain the extra hour. I suppose if this
weird effect goes away in June or July (in European Summer) then we can
assume there's something to do with swiss daylight savings going on.

NOTE: also, see cracksmokingducks.com/time.php - this shows that local
time (which is set to GMT on my server anyway) taken straight from the
clock gives the correct net time when formatted with date() (check
http://www.swatch.com/internettime/home.php to verify current net time)

------------------------------------------------------------------------

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
    http://bugs.php.net/33082

-- 
Edit this bug report at http://bugs.php.net/?id=33082&edit=1

Reply via email to