php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60257 ZERO DATES IN STRTOTIME
Submitted: 2011-11-10 23:40 UTC Modified: 2011-11-11 12:25 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:3 (100.0%)
From: it at ezy2c dot com Assigned:
Status: Duplicate Package: Date/time related
PHP Version: 5.3.8 OS: CENTOS 5 64 bit
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: it at ezy2c dot com
New email:
PHP Version: OS:

 

 [2011-11-10 23:40 UTC] it at ezy2c dot com
Description:
------------
Hi I have noticed that when i use zero date in windows it converts to the expected 1970 date however on our Centos 5 Server it fails.

See live script http://amo2.flsecure.com/testdate.php

Test script:
---------------
EXAMPLE CODE:
$zerodate="0000-00-00 00:00:00";
$convertdate=date("Y-m-d H:i:s",strtotime(0000-00-00 00:00:00));
echo("ORIG: ".$zerodate." | CONVERTED: ".$convertdate.");

RESULT:
ORIG: 0000-00-00 00:00:00 | CONVERTED: -0001-11-30 00:00:00

On MY WINDOWS BOX:
ORIG: 0000-00-00 00:00:00 | CONVERTED: 1970-01-01 10:00:00


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-11-11 03:08 UTC] it at ezy2c dot com
After a search of the web I have uncovered that other users experience this in lots of 5+ versions of PHP on 64-bit *unix OS's. 

If its a 64 bit OS, strtotime should detect if its a ZERO date value (as mysql uses as default value etc) ie. 0000-00-00 00:00:00 and return the 1970 value as my Windows machine does.

By the way my Windows Machine is a 64-Bit Windows 7 machine with XAMPP, and it returns a 1970 date. Please Fix this as we have a LOT of code that relies on strtotime's ability.
 [2011-11-11 03:31 UTC] it at ezy2c dot com
When I strtotime("0000-00-00 00:00:00") in the Linux Box I get -62170020000, when I do it on the windows box it returns NULL. Maybe this is the root of the issue, at least when it returns NULL it converts to 1970-01-01 10:00:00
 [2011-11-11 12:25 UTC] aharvey@php.net
-Status: Open +Status: Duplicate
 [2011-11-11 12:25 UTC] aharvey@php.net
Not a bug: on 64 bit platforms, 0000-00-00 00:00:00 is within range, so 
strtotime() returns a UNIX timestamp corresponding to that date. On 32 bit 
platforms, it's out of range, so strtotime() returns NULL to signal the error.

Duplicate of bug #53662 (among others).
 [2011-11-13 21:44 UTC] it at ezy2c dot com
Perhaps there should be an option to return NULL. This isnt great when your dealing with MySQL databases that have date fields with 0000-00-00 00:00:00 format. At least when it returns null the date field interprets it as the 1970 date. This is an expedted date wince 1970 is the start of unix epoch.

This Created variability over 32-bit and 64-bit systems and hence would need to adjust the code base to do something kind of work around (however some systems use lots of date values and this is VERY difficult to replace all the strtotime references) see below for a wrapper function. I feel that this logic SHOULD exist in 64 bit ONLY if the date is 0000-00-00 00:00:00, this way database default values can be handles easier and is cross compatible in both 64 or 32 bit systems. 

YOUR view maybe that is isnt a BUG, however its more of Incompatibility and Inconsistency across platforms and 32/64 bit systems. I would VERY much like you to consider changing this.

function str2time($time)
{
	if(strtotime($time)=="-62170020000")
	{
		return NULL;
	}
	else
	{
		return strtotime($time);
	}
}
 [2011-11-13 21:51 UTC] it at ezy2c dot com
Wow, OK. The Spell check went horrible. :)

However the 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.
 [2011-11-14 02:53 UTC] it at ezy2c dot com
This bug is obviously a duplicate because many people feel its a mistake and affects their database driven enterprise sites.

I would very much appreciate it if I could request for an extra parameter to be added ie. strtotime ( string $time [, int $now = time() ], [legacy32bit = boolean] )

So when its used on a 64-bit system (if you dont want to return an ambiguous date) you can specify to return the unix epoch as it did in 32-bit.

A lot of small companies start at 32-bit and their code uses strtotime and due to this problem it CANNOT be easily ported/upgraded to 64-bit as their company expands.

While its great to see that you support a large range of dates (292 billion years into the past and 292 billion years into the future) its not always wanted or necessary or useful when you are dealing with common dates your converting for enterprise purposes.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC