What calendar is Mathematica using for dates in the distant past?

32

3

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.}

orome

Posted 2012-11-24T20:50:35.590

Reputation: 12 197

@raxacoricofallapatorius Can you give an answer to this yet? Whatever you got I think will be good. – C. E. – 2014-01-12T15:08:10.200

1@Anon: "Premier" "Support" is still dragging its feet. I don't think they know. – orome – 2014-01-12T15:19:13.003

2Still there in version 10.0.0.0 – rhermans – 2014-08-01T10:05:10.537

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 ennui – 2012-11-25T04:15:44.167

@J.M.: OS X: 1353817092. – orome – 2012-11-25T04:19:05.037

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 ennui – 2012-11-25T04:43:46.037

1I'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 – 2012-11-25T08:24:20.147

1

@Mechanicalsnail: Yes, that's an additional issue, with leap seconds.

– orome – 2012-11-25T15:01:44.407

@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 – 2012-11-26T03:12:06.820

@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 – 2012-11-29T18:25:59.970

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 – 2012-11-29T18:28:23.810

2Wolfram 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 – 2012-12-08T18:01:53.413

@raxacoricofallapatorius Please post that as an answer – Verbeia – 2013-02-20T04:08:14.883

@Verbeia: Wolfram "support" still hasn't given me a straight answer about the rest of the question. I'm working on it. – orome – 2013-02-20T04:17:11.943

@raxacoricofallapatorius Ok! Keep us posted. – Verbeia – 2013-02-20T04:28:46.903

Answers

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

Posted 2012-11-24T20:50:35.590

Reputation: 653