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

go to bug id or search bugs for

Request #60288 ZERO DATES IN STRTOTIME
Submitted: 2011-11-14 03:16 UTC Modified: 2017-03-24 06:54 UTC
Votes:15
Avg. Score:4.5 ± 0.8
Reproduced:14 of 15 (93.3%)
Same Version:7 (50.0%)
Same OS:6 (42.9%)
From: it at ezy2c dot com Assigned:
Status: Wont fix Package: Date/time related
PHP Version: 5.3.8 OS: CENTOS 5 64 bit
Private report: No CVE-ID: None
View Developer Edit
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: it at ezy2c dot com
New email:
PHP Version: OS:

 

 [2011-11-14 03:16 UTC] it at ezy2c dot com 
Description:
------------
If you could please include a 3rd switch to strtotime ( string $time [, int $now = time() ], [legacy32bit = boolean] )


This would both allow large date ranges as well is be backwards supporting of database default timestamps ie 0000-00-00 00:00:00 they get converted to an ambiguous -0001-11-30 00:00:00.

if it was used like this strtotime($DBROW['timestampcolumn'], time(), true) and it returns NULL as it did in the 32-bit version this whole issue could be avoided and it can still support a very large date range.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-11-14 03:17 UTC] it at ezy2c dot com 
The Optional parameter could be set to DEFAULT of TRUE, that way it works as it would on 32-bit. However if you want to use a date 292 billion years ij the past or future, specify FALSE.
 [2012-02-20 21:01 UTC] john at gbd dot co dot uk 
as 0000-00-00 is a non-existant date (the day before 01-01-0001 was 31/12/-0001) 
then strtotime() should return NULL on all systems
 [2012-02-20 21:34 UTC] it at ezy2c dot com 
Physically 0000-00-00 00:00:00 is NOT a real date, however all major databases commonly use this as a default datetime value to differentiate between a valid and and an invalid date.
 [2017-03-24 06:54 UTC] heiglandreas@php.net
-Status: Open +Status: Wont fix
 [2017-03-24 06:54 UTC] heiglandreas@php.net 
On the other hand, checking for "0000-00-00 00:00:00" before throwing the date into DateTime would also solve the issue and be much cleaner. In the end the "0000-00-00 00:00:00" is the databases way of saying "this database-field has a NULL value". And would you pass that to DateTime you'd get the current date which is not what you want. 

So I'd not see this as  a bug in DateTime but in your code when you're passing DateTime wrong information. Adding a further flag that needs maintenance and adds to the complexity of DateTime is IMHO not the right way to handle this.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Apr 26 02:01:28 2025 UTC