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 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: 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: Thu Nov 21 22:01:28 2024 UTC