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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: benjamin dot rich at gmail dot com
New email:
PHP Version: OS:

 

 [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 13:00:02 2025 UTC