php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33110 date("B") returns wrong net time - or does it?
Submitted: 2005-05-23 13:11 UTC Modified: 2005-05-26 06:16 UTC
From: benjamin dot rich at gmail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 4.3.10 OS: Linux, Mac OSX
Private report: No CVE-ID: None
 [2005-05-23 13:11 UTC] benjamin dot rich at gmail dot com
Description:
------------
I was hyperventilating trying to solve a seemingly phantom bug in my script to do with net time (see bug 33082).

It appeared, when I got down to it, that when I calculated net time with date() from the local clock, it would give me the correct net time:

date("B", time());

but when I did it from a static timestamp - adjusted to local time - it showed the date and time correctly, but always screwed up the net time:

//6:41am 2005-5-20 GMT:
$test = date(@B", mktime(06,41,00,05,20,2005));
echo "should show @361: $test";

-> @403

I tried for some time to figure out why - it seemed - the date() function was adding an hour to the net time for these dates - and not, as I later found out through experimentation, the actual date or time they represented. For example, date("r @B") for the above might give me: fri 20 may 2005 06:41am  @403.

After long and painful, and unscientific, experimentation, I finally discovered the problem: the time it was giving *was* right - just not according to every net time calculator I entered the time into.

For example - enter the date/time  5th May 1999, 6:41pm  with location Austtralia, SYDNEY into one of the following net time calculators:

http://www.help4web.net/adds/swatch.html
and you get @361

http://www.users.bigpond.net.au/snakeman/converter.html
and you get @403

Swatch's own converter thinks different:

http://www.swatch.com/internettime/home.php
gives @361

yet PHP's date() function will give you: @403.

Something, somewhere, is not... calculating daylight savings correctly? It would appear something is awry. I thought I should bring this to the attention of the PHP devs.

I mean... sure, nobody *uses* net-time... but come on! That's no excuse not to make it work properly =)

For my own money, my own calculations show 403 is the correct net time for the above date. I worked it out as:

Australia (Sydney) is EST, and during May, which is not daylight savings time, is GMT+10. Given that BMT, net time's meridian, is GMT+1, this means the net time for any given time in Australia is: ((Australian time in hours) - 9) * 41.666.

41.666 is the number of net-time 'beats' per hour. The above yields an answer of 403 for the given date/time (18:41 EST time 2005-5-20)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-26 00:18 UTC] sniper@php.net
# export TZ="Australia/Sydney"
# php -r 'echo date("B", mktime(18,41,0,5,5,1999, 1)), "\n";'
361

..so I see no bug here. (note the last parameter to mktime())

 [2005-05-26 06:15 UTC] benjamin dot rich at gmail dot com
# php -r 'echo date("B", mktime(18,41,0,5,5,1999, 1)), "\n";'
361

I see a bug. Notice how you entered 5/5/1999 and I entered 20/5/1999?

Notice also: I'm not saying this is necessarily a bug. Since several different scripts, as well as swatches own 'net time calculator' on the web disagree with PHP's projected net time on this (and other) dates, I think the disparity is worth looking into by one of the developers who handles the net-time routine.
 [2005-05-26 06:16 UTC] benjamin dot rich at gmail dot com
And the date you entered isn't within daylight savings (from october to march), so you needn't include a '1' in that last field in mktime.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Sun Aug 03 11:00:03 2025 UTC