Java scentific date hanlding

Question

My question is how should a Date be handled when we want to store dates since the birth of earth until end of earth (expected to be at 100000000000000000000-12-31 23:59:00.0000 +1 ).

I am sure some scientists have libraries for Dates like these. Since Joda-Time is also using a long for internal storage it is out of scope. Developing a calender from scratch could be difficult since we have to handle all the special cases like switching from julian to gregorian calendar and leap years/seconds ...

Answer 1

JSR-310 - the new date/time API in Java 8 - handles this already. From the Instant docs:

For practicality, the instant is stored with some constraints. The measurable time-line is restricted to the number of seconds that can be held in a long. This is greater than the current estimated age of the universe. The instant is stored to nanosecond resolution.

There is a backport to Java 7, if you can't wait for Java 8 to come out :)

However, JSR-310 may not handle leap seconds in the way that you want it to. Basically it tries (entirely reasonably) to remove leap seconds from the system, by insisting that any clocks provided perform smearing. (So the leap second isn't represented in the data model.) You'll need to be careful around that. Of course, dates in the far future make leap second calculations impossible and almost certainly insignificant anyway :)

EDIT: As noted in the answer below, the quote above is effectively a spec error, and Instant will "only" support year values up to a billion.

Answer 2

No there is no such library which supports years like 100000000000000000000, not even JSR-310.

Jon Skeet has correctly read the spec of java.time.Instant (which claims to support any number of seconds which can be held in a long) but forgotten to also read the details of the API-elements MAX and MIN which are clearly constrained to absolute year numbers of 1 billion and less. So we just have a spec error in JSR-310. Any try to get bigger year numbers will end in a RuntimeException. By the way, the JSR-310-team has already become conscious of the spec error and will fix it, see Oracle-Bug-Log.

And these wishes for taking in account calendar rules like leap year or even leap seconds. Well, Peter Lawrey has done a good comment. I would just add following to consider:

Leap seconds are only supported in my library Time4J, not in JSR-310. But this feature does not make any sense for your actual problem because leap seconds cannot be predicted more than ca. six months in advance! So this calculation is pretty silly. Furthermore and surprising for many people: Even leap year rules in gregorian calendar will not be stable beyond a scope of about 3000-4000 years in the future because the gregorian calendar is only an imperfect approximation to the true solar year.

So my advise, just forget any calendar libraries for your problem and use a double primitive. This is good enough.