Home Original page

PHP :: Bug #32555 :: strtotime("tomorrow") can return false

Bug #32555 strtotime("tomorrow") can return false
Submitted: 2005-04-03 09:08 UTC Modified: 2005-06-18 21:26 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: stickman at gmail dot com Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: 5.0.3, 4.3.10 OS: FreeBSD 4.9
Private report: No CVE-ID: None

 [2005-04-03 09:08 UTC] stickman at gmail dot com

Description:
------------
Early morning on April 2nd, 2005 my website broke. I tracked it down to strtotime("tomorrow") returning -1 instead of the expected "tomorrow" timestamp. strtotime("today") worked fine.

Asked a friend to test strtotime("tomorrow") and it worked fine for him on his server (set to a different time).

Tested strtotime("tomorrow") on another server, also on Pacific time, and got false again.

Went to bed to deal with it in the morning and the problem had resolved itself sometime between midnight and 7am.

Reproduce code:
---------------
#Run this code on April 2nd, sometime after midnight.
echo strtotime("tomorrow");

Expected result:
----------------
1112628800 (or thereabouts)

Actual result:
--------------
-1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2005-04-03 09:17 UTC] stickman at gmail dot com

Well duh. I didn't even notice but daylight savings is about that time. Could it be that "tomorrow" didn't exist for an hour?

 [2005-04-03 15:58 UTC] derick@php.net

Correct. Although I'm not totally sure what "tomorrow" should do here then...

 [2005-04-03 18:17 UTC] stickman at gmail dot com

Is there some kind of RFC for this? There's one for everything down to slicing bread.

RFC 3339 - Date and Time on the Internet: Timestamps
The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time.  This specification steers well clear of such considerations.)

No wonder they do. Daylight Saving Time is scary. It starts at 1:59am and hops ahead one hour and one minute to 3am. It's at different times across the world (12:59am Western Europe, 1:59am US, 2:59am Eastern Europe, different for every area of Russia). Arizona and Hawaii don't have it, Indiana sort of has it, and it's on a different day every year and different days across the world.

Good luck, sir.

 [2005-04-05 22:31 UTC] derick@php.net

I know about DST and stuff - i was just wondering what tomorrow should do for 2.30am on the day before DST changes... that's not in the RFC ;-)

 [2005-04-05 23:25 UTC] web-php-bugs at sklar dot com

With PHP 4.3.9, 5.0.3, and a recent CVS checkout, the following script (run in timezone US/Eastern):

<?php
$stamp = 1112427000;
print strftime('%c',strtotime('now',$stamp)) ."\n";
print strftime('%c',strtotime('tomorrow',$stamp)) ."\n";
?>

produces:

Sat Apr  2 02:30:00 2005
Sun Apr  3 03:30:00 2005

Which seems like a reasonable way for strtotime() to behave when it's called without a starting timestamp during the period that's less than 24 hours but more than 23 hours before a change to DST in a DST-respecting locale. That is, report the local time that corresponds to 86400 seconds after strtotime() is called.

 [2005-06-18 21:26 UTC] derick@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Fixed for PHP 5.1