php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #46597 Inconsistent return values for strtotime('0000-00-00')
Submitted: 2008-11-17 17:41 UTC Modified: 2010-03-31 16:17 UTC
Votes:5
Avg. Score:3.8 ± 0.7
Reproduced:4 of 5 (80.0%)
Same Version:1 (25.0%)
Same OS:2 (50.0%)
From: fsb at thefsb dot org Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.*, 6CVS (2009-04-30) OS: *
Private report: No CVE-ID: None
View Developer Edit
 [2008-11-17 17:41 UTC] fsb at thefsb dot org 
Description:
------------
strtotime('0000-00-00') returns int(-62169955200) in a script run by 
apache web server and bool(false) when run by the command line.




Reproduce code:
---------------
<?php
var_dump(strtotime('0000-00-00'));
?>
this script outputs int(-62169955200) to the web browser when run as a web page and bool(false) when run on the command line.

Expected result:
----------------
i would expect the same result from running the function in the two 
contexts. 

regarding which result strtotime('0000-00-00') should return, i don't 
know. both answers seem reasonable to me. it would help if php 
documentation would specify the range of dates and unix timestamps that 
date and time functions can handle.

Actual result:
--------------
int(-62169955200) in the web page
bool(false) in the command line

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-11-17 18:33 UTC] fsb at thefsb dot org 
i was wrong with the expected results. a year of 0000 is reasonable but 
neither month = 00 nor day of of the month = 00 are possible, so the 
strtotime('0000-00-00') should return bool(false)
 [2009-01-16 18:24 UTC] marco at tumis dot com 
I've reproduced this on CentOS with kernel 2.6.9-55.ELsmp using php version:

PHP 5.2.8 (cli) (built: Jan  5 2009 15:01:45) 
and the 5.2.8 apache module.

And I think it should go back to returning bool(false).
 [2010-03-30 22:09 UTC] contractfrombelow at gmail dot com 
We are getting this same problem, but only on 64 bit platforms. I've tested on a 
few different machines, all 64 bit machines return int(-62169955200). 32 bit 
machines return bool(false) as expected. This happens on 5.2.x and 5.3.x.
 [2010-03-31 05:17 UTC] aharvey@php.net
-Status: Verified +Status: Bogus
 [2010-03-31 05:17 UTC] aharvey@php.net 
This isn't a bug. The year 0 is well within the range of a 64-bit UNIX
timestamp, strtotime's semantics for invalid values (such as
defining the month and day as 0) are well established at this point,
and I see little value in special casing 0000-00-00 and plenty of
possible WTFs down the line if it's done.
 [2010-03-31 15:21 UTC] fsb at thefsb dot org 
aharvey@php.net: Any date with month=zero or day=zero is invalid, regardless of 
the year value. '0000-00-00' is not a date and has no corresponding unix 
timestamp.
 [2010-03-31 16:17 UTC] aharvey@php.net 
Sure, but strtotime() has long handled invalid month and day values the same way as mktime() by effectively "rounding" them into valid values: the 0th day of the month becomes the last day of the previous month, the 0th month is the last month of the previous year, and so on. Given that interpretation, 0000-00-00 fairly obviously becomes the last day of November in the year -1 (better known as 2 BCE).

There's no chance that behaviour is going to be changed now: checkdate() is a much better way of sniffing out invalid dates anyway, and it would be a potentially nasty backward compatibility break for people relying on this behaviour in strtotime().
 [2010-03-31 16:34 UTC] fsb at thefsb dot org 
Thank you for the explanation.
 [2011-09-01 16:02 UTC] tom at kera dot name 
@aharvey: There was no year 0. 1BC was followed by 1AD, and YYYY-MM-DD date format, to the best of my knowledge, assumes AD.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 23 23:01:27 2024 UTC