|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
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.
Block user comment
Status: Assign to:
Bug Type:
From: berthier at imcce dot fr
New email:
PHP Version: OS:


 [2009-03-19 18:28 UTC] berthier at imcce dot fr
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:
$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!


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-20 01:59 UTC]
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-2024 The PHP Group
All rights reserved.
Last updated: Wed Feb 28 17:01:30 2024 UTC