|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #53662 strtotime() returns inconsistent output on 64 bit systems
Submitted: 2011-01-06 02:54 UTC Modified: 2011-07-02 20:41 UTC
Avg. Score:4.2 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:3 (75.0%)
Same OS:1 (25.0%)
From: smenjas at gmail dot com Assigned: frozenfire (profile)
Status: Closed Package: Date/time related
PHP Version: 5.3.4 OS: Ubuntu 10.10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: smenjas at gmail dot com
New email:
PHP Version: OS:


 [2011-01-06 02:54 UTC] smenjas at gmail dot com
From manual page:
strtotime() produces different output on 32 and 64 bit systems running PHP 5.3.  
This affects the "zero date" ("0000-00-00 00:00:00") as well as dates outside the 
traditional 32 date range.

strtotime("0000-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("0000-00-00 00:00:00") returns -62169955200 on a 64 bit system.

Test script:

var_export(strtotime("0000-00-00 00:00:00"));


Expected result:
On 64 bit systems, I would expect strtotime("0000-00-00 00:00:00") to return 
FALSE as it does on 32 bit systems.

Actual result:
On 64 bit systems, strtotime("0000-00-00 00:00:00") returns -62169955200.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-06 02:57 UTC]
-Status: Open +Status: Bogus
 [2011-01-06 02:57 UTC]
This is expected.  On 64-bit systems the date range supported is much larger than 
on 32-bit systems.
 [2011-01-06 03:12 UTC] smenjas at gmail dot com
Thanks for the incredibly prompt reply.

That makes sense, except that to the best of my knowledge the year zero is not valid in either the Julian or Gregorian calendars.

I had assumed that strtotime would return FALSE for invalid dates.  On my 32 bit Ubuntu system, this appears to the case.  strtotime("2011-01-32") returns FALSE, as opposed to returning the timestamp for "2011-02-01".

An in depth reading of the documentation did not clarify how strtotime() should be expected to handle invalid date strings.
 [2011-01-06 03:49 UTC]
PHP uses the version of the proleptic Gregorian calendar specified by
ISO 8601, which does include a year 0 (equivalent to 1 BC in the
traditional Gregorian calendar).
 [2011-01-06 04:07 UTC]
And you get false in 32-bit systems because year 0 falls outside the supported 
range that fits in a 32-bit signed integer.  The range for 32-bit covers about 136 
years starting at 1901-12-13 and ending at 2038-01-19
 [2011-01-06 04:20 UTC] smenjas at gmail dot com
Thanks for taking the time to point that out, and thanks for PHP!
 [2011-01-06 11:40 UTC]
For a read on the used calendar:
 [2011-01-06 11:44 UTC]
-Status: Bogus +Status: To be documented
 [2011-01-06 11:44 UTC]
Blog post are not documentation, if the docs do not have this info then let mark 
this bug as "to be documented".
 [2011-01-07 14:39 UTC]
-Type: Bug +Type: Documentation Problem
 [2011-01-24 18:03 UTC] tjw at tjw dot org
Shouldn't "0000-00-00 00:00:00" return false because there is no 00 month or 00 day in any month?
 [2011-01-24 18:07 UTC] tjw at tjw dot org
Nevermind, I see this underflow/overflow behavior is documented here  It might be nice if there were a "strict" option to turn this behavior off, but that's another story.
 [2011-01-24 18:10 UTC] vita10gy at charter dot net
If you pass the returned timestamp back to date() you get -0001-11-30 00:00:00

0 might be a valid year, 0 isn't a valid month or day. 

Database dates can be nothing or 0000-00-00 00:00:00 if null isn't allowed, so the easiest check for both is to see if strtotime === false, or not. Obviously there are workarounds, but depending on the feasibility of changing lots of legacy code, this could be a show stopper for upgrading.

0000-00-00 00:00:00 is a nonsensical date and the timestamp returned is nonsense. Please return false.

Pretty please? :)
 [2011-01-24 18:25 UTC] vita10gy at charter dot net

Well then I second adding some sort of strict date option to the server config options where 2010-08-36 and 0000-00-00 are NOT valid, since documented or not, we could debate if that's a bug or a feature. :)
 [2011-07-02 20:41 UTC]
-Status: To be documented +Status: Closed -Assigned To: +Assigned To: frozenfire
 [2011-07-02 20:41 UTC]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

 [2011-10-26 00:24 UTC] rich at clearchaos dot com
Another vote for adding "0000-00-00 00:00:00" as a special case that returns a timestamp of false (or make all zero days/months return false).

The problem is that value is often used in MySQL datetime fields as a "null". Code written for 32-bit PHP often checks whether this equates to a zero timestamp to see whether the value is set. This may not be best practice, but it happens in the real world (just had to debug code with this problem myself).
 [2011-11-13 22:07 UTC] steg2005 at gmail dot com
Logic of strtotime SHOULD BE:

Strtotime -> IF Running on 64-Bit AND input is 0000-00-00 00:00:00 then return NULL.

Its fine if the date is in the past, just NOT when its 0000-00-00 00:00:00 (the default for date column value in MANY databases).

This creates inconsistency in the PHP language across platforms is what im trying to say. It may not be a BUG but it makes PHP less of a reliable language due to the unexpected behaviour, and I'd like to see you SERIOUSLY consider fixing this.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed May 31 16:03:37 2023 UTC