33

It appears that Mathematica treats all dates as proleptic Gregorian dates by default, a hypothesis that can be easily tested by using AbsoluteTime to compute the Julian Day:

jd[t_] := AbsoluteTime[t]/86400 + 2.4150205*^6

but, while this works for recent dates and for some older ones, it yields results that differ from the correct result for some older dates by exactly a day

jd[{2012, 11, 24, 12}] - 2456256
0
jd[{1100, 11, 24, 12, 0, 0}] - 2123154
0
jd[{-3000, 11, 24, 12, 0, 0}] - 625660
1

notably for the reference date, 12:00 Universal Time on January 1, 4713 BCE in the proleptic Julian calendar (-4713-11-24 in the proleptic Gregorian calendar):

jd[{-4713, 11, 24, 12, 0, 0}]
1

What calendar is Mathematica using for these older dates, if not the proleptic Gregorian calendar?

Here, perhaps is another clue:

DateList[{-4713, 11, 24, 12, 0, 0}]
{-4713, 11, 25, 12, 0, 0}
DateList[{-3000, 11, 24, 12, 0, 0}]
{-3000, 11, 25, 12, 0, 0}

I'm no calendar expert, but this "canonicalization" doesn't map to any calendar I'm familiar with. Is this a bug?

Update: Version 9, behaves differently:

jd[{2012, 11, 24, 12}] - 2456256
0.
jd[{1100, 11, 24, 12, 0, 0}] - 2123154
0.
jd[{-3000, 11, 24, 12, 0, 0}] - 625660
365.

jd[{-4713, 11, 24, 12, 0, 0}]
366

and

DateList[{-4713, 11, 24, 12, 0, 0}]
{-4713, 11, 24, 12, 0, 0.}
DateList[{-3000, 11, 24, 12, 0, 0}]
{-3000, 11, 24, 12, 0, 0.}
Community
  • 1
orome
  • 12,819
  • 3
  • 52
  • 100
  • I can't test now, but just on a hunch: if you're on a Linux system, could you compare what happens if you use Unix time (e.g. via Get["!date +%s"]) to compute JD? – J. M.'s missing motivation Nov 25 '12 at 04:15
  • @J.M.: OS X: 1353817092. – orome Nov 25 '12 at 04:19
  • Eek, Get["!date +%s"] just computes Unix time! What I wanted to say was that you could try reckoning the formula for JD based on Unix time, and then compare with the method using AbsoluteTime[] and the true JD. – J. M.'s missing motivation Nov 25 '12 at 04:43
  • 1
    I'm guessing it's just a bug. Similarly, AbsoluteTime[{2009,01,01,0,0,0}]-AbsoluteTime[{2008,12,31,23,59,59}] gives 1 instead of the correct 2, assuming the standard UTC+Gregorian. – Mechanical snail Nov 25 '12 at 08:24
  • 1
    @Mechanicalsnail: Yes, that's an additional issue, with leap seconds. – orome Nov 25 '12 at 15:01
  • @J.M.: I believe I'm POSIX compliant, but that's the extent of my understanding; that is, UNIX time: a duplicated first post-leap-second second, that always maps back to the first second of the following day, and is not counted in time differences. Essentially: UTC with gaps where leap seconds should be. But that doesn't account for the behavior I see (e.g. AstronomicalData skips leap seconds, but reports results as if there were no gap). – orome Nov 26 '12 at 03:12
  • @J.M.: Updated with different behavior in 9.0. DateList does (did) indeed seem to have a bug (that's now fixed). I'm not sure what's going on with AbsoluteTime, but it's probably not the way to calculate JD. – orome Nov 29 '12 at 18:25
  • 1
    @Mechanicalsnail: AbsoluteTime[{2009, 01, 01, 0, 0, 0}] - AbsoluteTime[{2008, 12, 31, 23, 59, 59}] still gives 1, in version 9.0, rather than 2. – orome Nov 29 '12 at 18:28
  • 2
    Wolfram support has confirmed that change of date by DateList was a bug in version 8. It remains to be seen why AbsoluteTime added a day in 8 and a year in 9. – orome Dec 08 '12 at 18:01
  • @raxacoricofallapatorius Please post that as an answer – Verbeia Feb 20 '13 at 04:08
  • @Verbeia: Wolfram "support" still hasn't given me a straight answer about the rest of the question. I'm working on it. – orome Feb 20 '13 at 04:17
  • @raxacoricofallapatorius Ok! Keep us posted. – Verbeia Feb 20 '13 at 04:28
  • @raxacoricofallapatorius Can you give an answer to this yet? Whatever you got I think will be good. – C. E. Jan 12 '14 at 15:08
  • 1
    @Anon: "Premier" "Support" is still dragging its feet. I don't think they know. – orome Jan 12 '14 at 15:19
  • 2
    Still there in version 10.0.0.0 – rhermans Aug 01 '14 at 10:05

1 Answers1

1

In version 10, I think that much of the behavior is simply a difference between how the year 0 is handled by astronomers (and therefore the page you were getting Julian Dates from) and everybody else.

For example, take this calculation:

jd[{-3000, 11, 24, 12, 0, 0}] - 625660

I believe that you have actually pulled the wrong number from the website due to a year 0 issue. Consider this:

(AbsoluteTime[{1, 1, 1, 12}] - AbsoluteTime[{-1, 1, 1, 12}])/86400

366

Note that Mathematica will return a result consistent with the Gregorian/Julian calendars where there is no year 0. But, your link reports that the Julian Day of 1,1,1,12 is:

1721426

and the Julian day of -1,1,1,12 is:

1720695

a difference of 2 years. This is consistent with how an astronomy specific app should work. If you account for this difference in years, I believe that the results will be consistent (in Mathematica 10, past results were just incorrect, as noted in comments).

KAI
  • 673
  • 3
  • 8