php.net |  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
Votes:4
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
Status: Closed Package: Date/time related
PHP Version: 5.3.4 OS: Ubuntu 10.10
Private report: No CVE-ID:
 [2011-01-06 02:54 UTC] smenjas at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.strtotime
---
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:
---------------
<?php

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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-06 02:57 UTC] rasmus@php.net
-Status: Open +Status: Bogus
 [2011-01-06 02:57 UTC] rasmus@php.net
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] aharvey@php.net
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] rasmus@php.net
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] derick@php.net
For a read on the used calendar: http://derickrethans.nl/unix-epoch-and-phps-calendar-system.html
 [2011-01-06 11:44 UTC] pajoye@php.net
-Status: Bogus +Status: To be documented
 [2011-01-06 11:44 UTC] pajoye@php.net
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] kalle@php.net
-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 http://us2.php.net/manual/en/datetime.formats.date.php.  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
Damn.

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] frozenfire@php.net
-Status: To be documented +Status: Closed -Assigned To: +Assigned To: frozenfire
 [2011-07-02 20:41 UTC] frozenfire@php.net
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-2014 The PHP Group
All rights reserved.
Last updated: Sat Apr 19 01:01:59 2014 UTC