I came across the XMLGregorianCalendar class a while ago and I was impressed by the way it made GregorianCalendar look lightweight. 😉
Recently, I noticed a method BitInteger getEon() which baffles me.
From the Javadoc for XMLGregorianCalendar
getYear() is a value between -(10^9-1) to (10^9)-1 or DatatypeConstants.FIELD_UNDEFINED.
getEon() is high order year value in billion of years.
It occurs to me that as the length of day on Earth changes significantly over the millions of year and there for the number of days in a year has changed. The Gregorian calendar wouldn’t make sense a billion years ago or a billion years hence. So getEon() can only be sensibly set to 0 or left undefined which has much the same outcome.
My question: Am I missing something? Is there a sensible use for the getEon() method?
Well, according to http://www.merlyn.demon.co.uk/critdate.htm the unix time using 64 bits integer will end around the year 3E11. Given that Java uses milliseconds instead of seconds, Java time (64 bits) will end around 3E8. So this provides some expansion beyond the limits of the JVM.
In a more practical note, when you use this scale of time you are talking about geological, evolutionary or cosmological events, so the rest of the data in a date (year, month, day…) is meaningless. It is better if you use a long with the year (or even an int with the eon) and forget about the rest of it.
It looks like somebody was really, really bored (and boring).
Edit: Of course, there is always some crazy problems that can use it, but not real world problems (as in: “if we have a Hanoi Towers with 64 discs and move a disc a second, when would we finish swapping the towers”).