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

go to bug id or search bugs for

Bug #47723 strtotime(JD) provides wrong timestamp for some JD
Submitted: 2009-03-19 18:28 UTC Modified: 2009-03-20 14:16 UTC
From: berthier at imcce dot fr Assigned:
Status: Not a bug Package: Calendar related
PHP Version: 5.2.9 OS: ArchLinux, CentOS (x86_64)
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2009-03-19 18:28 UTC] berthier at imcce dot fr 
Description:
------------
For the first 365 days of each millennium, the function strtotime() applied on a Julian Day provides a Unix timestamp whereas it should not. Moreover, the Unix timestamp is wrong and always ranges between 110638652400 and 110670188400.

This bug exists for php 5.2.9 on ArchLinux 2009-02 kernel 2.6.28 x86_64
and also for php 5.2.6 on CentOS 5.2 kernel 2.6.18 x86_64. It does not exist for php 5.2.6 on OpenSuse 11.1 kernel 2.6.27 i686.




Reproduce code:
---------------
<?php
$epoch_0 = 2400000.5476;
for ($i=0; $i<=100000; $i++) {
  $epoch = $epoch_0 + $i;
  if (($timestamp = strtotime($epoch)) === FALSE) {
    echo $epoch." == not a timestamp!\n";
  } else {
    echo $epoch." == timestamp = ".$timestamp." ; JD = ".unixtojd($timestamp)."\n";
  }
}
?>

Expected result:
----------------
2400000.5476 == not a timestamp!
2400001.5476 == not a timestamp!
2400002.5476 == not a timestamp!
...
2400365.5476 == not a timestamp!
2400366.5476 == not a timestamp!
2400367.5476 == not a timestamp!


Actual result:
--------------
2400000.5476 == not a timestamp!
2400001.5476 == timestamp = 110638652400 ; JD = 3721128
2400002.5476 == timestamp = 110638738800 ; JD = 3721129
...
2400365.5476 == timestamp = 110670102000 ; JD = 3721492
2400366.5476 == timestamp = 110670188400 ; JD = 3721493
2400367.5476 == not a timestamp!

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-20 01:59 UTC] scottmac@php.net 
You can use parse_date() to see what it is doing here, its taking the digits directly before the period as the day of the year and the part after as the year.

I'm not sure why its not happening on your OpenSuse machine, but I get this behaviour on all the 5.2.9 builds I tested and I don't see a problem with what its doing.

strtotime() is designed to try and parse a date from various weird exotic formats.
 [2009-03-20 14:16 UTC] berthier at imcce dot fr 
strtotime() is designed to try and parse a date from various weird
exotic formats, any English textual datetime description as it is written in the php doc. So I don't understand why it should not return false (or a valid timestamp) for all julian days (which are not considered as textual datetime). This behaviour is (at least for me) a problem as it returns a wrong information which is not useful.
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved. 		Last updated: Tue Mar 28 09:03:46 2023 UTC