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

go to bug id or search bugs for

Bug #30215 strtotime returning huge timestamps instead of -1
Submitted: 2004-09-24 05:21 UTC Modified: 2005-06-30 08:58 UTC
Votes:38
Avg. Score:4.6 ± 0.7
Reproduced:36 of 36 (100.0%)
Same Version:11 (30.6%)
Same OS:25 (69.4%)
From: pmurray at nevada dot net dot nz Assigned: derick (profile)
Status: Not a bug Package: Date/time related
PHP Version: 5.*, 4.* OS: Linux 64bit - Opteron
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: pmurray at nevada dot net dot nz
New email:
PHP Version: OS:

 

 [2004-09-24 05:21 UTC] pmurray at nevada dot net dot nz 
Description:
------------
When using strtotime(), it returns a bogus timestamp instead of -1.

Gentoo 64bit (Opteron) 2004.2, Glibc 2.3.4, PHP 4.3.8; strtotime(time()) returns 3396548642400

Gentoo 32bit (Pentium 4) 2004.2, Glibc 2.3.3, PHP 4.3.8 returns -1

FreeBSD 32bit, PHP 4.3.8 and 5.0.1 returns -1

This causes the examples in the date_format modifier page in the Smarty documentation to fail. IE

{$smarty.now|date_format:"%Y"} 

Could this be related to being on a 64bit platform?

Reproduce code:
---------------
strtotime(time());



Expected result:
----------------
Return -1

Actual result:
--------------
Return 3396548642400

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-11 18:18 UTC] sstillwell at aerostich dot com 
PHP Version: 4.3.2-19 (RHEL)
OS: RHEL x86_64
CPU: Dual Intel Xeon 2.8 EM64T

I am getting this same bug as well.

This code
print strtotime(time());

Produces this 
3434798239200

Looks like PHP is not quite ready for 64 bit plateforms at this time.
 [2005-02-13 19:48 UTC] borishim at hotmail dot com 
I could reproduce this on 6.0-CURRENT of FreeBSD/amd64 box 
(which is 64bit OS also.)
 [2005-05-11 13:59 UTC] olivier at oxeva dot fr 
I could reproduce this bug on Bi-Xeon; fedora rc3
 [2005-05-17 09:40 UTC] weecka at stablebeast dot com 
I get the same bug with PHP 5.0.4
mmOK..
 [2005-06-16 21:31 UTC] derick@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip
 [2005-06-17 00:51 UTC] pmurray at nevada dot net dot nz 
Something's changed, but it still doesn't behave properly. 

pmurray@wildfire:~/php5-200506162030/sapi/cli> echo "<? print 
strtotime(time()) . \"\n\"; ?>" | ./php 
-42492861720
 [2005-06-18 21:44 UTC] derick@php.net 
I've no access to a 64bit machine. A temporary account would help here - let me know by mail if you can provide one.
 [2005-06-26 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-06-27 15:24 UTC] arpad at zooloo dot com 
derick@php.net:
I'm not sure if this is related but beta2 on 32bit windows behaves a lot worse than beta1 did:
echo strtotime(1118936460); results in 1119871080 which does not make sense.
This worked perfectly with beta1.
I have not yet tested this on my 64bit gentoo.
 [2005-06-29 14:46 UTC] derick@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

I just tested this on a 64bit platform, it returns bool(false) (like it should):

[derick@content php5-200506291030]$ sapi/cli/php -r 'var_dump(strtotime(time()));'
bool(false)
 [2005-06-29 20:35 UTC] derick@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Actually, after debugging this I would consider it as not a bug. What happens is the following:
1. time() returns (something like): 1120069874
2. parsetotime() sees this correctly as "number"
3. the number > 10000 so it applies the following rules:
   ((struct date_yy *)parm)->yyHaveDate++;
   ((struct date_yy *)parm)->yyDay= ($1)%100;
   ((struct date_yy *)parm)->yyMonth= ($1/100)%100;
   ((struct date_yy *)parm)->yyYear = $1/10000;
4. This turns out to be year 112006, month 98 and day 74.
5. The correct timestamp for this is: 3472662258000

Morale: Don't pass time()'s return value to strtotime() as it might "weird", though correct, behave.
 [2005-06-30 02:45 UTC] pmurray at nevada dot net dot nz 
Yes, it is indeed fixed in 5.1 CVS now.

Is there any chance at all this will get a fix for people 
using PHP4 on 64bit?
 [2005-06-30 08:26 UTC] derick@php.net 
How would you fix it, it's not broken... it merely does something you don't expect. strtotime() is supposed to take a string describing an english date, not a timestamp.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Nov 24 15:01:36 2024 UTC