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! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 13:01:31 2024 UTC