Share via


Dates and flagging some sort of condition

Occasionally I get strange questions about things like "why does the calendar end in 9999?" or "how come my maxdate Dec 31, 9999 blows up for this Arabic user?"

Well, each calendar has a "supported date range", which is sometimes kind of arbitrary, but other times is related to limitations of know information.  Some have official adjustment tables that only include the next several years.  Some have a "natural" 9999 that is different than Gregorian's 9999 date, etc.

Developers often look for a way to signal some sort of a condition.  Maybe choosing "never expires" as 9999.  Then they convert that to some other calendar and it's out of range.  Or the value gets fed through timezone conversion software that adds a couple hours and blows up because its now outside of the Gregorian range.

Better would be to have an explicit flag that says "This data never expires" or "Nobody entered a date yet" than using some sort of min or max time stamp to indicate those dates.  If you do need to encode such a concept into a date object, then be careful about how that flag is consumed.  It could cause exceptions or, perhaps worse, lose it's meaning.  (Subtract the timezone and maybe you end up with a smaller date that your app no longer recognizes as a flag).

Another point is "think about it".  9999 is pretty far out there.  About 4x longer than the period from 1AD to now.  That's not even 4x longer than the calendar has been in existence because it wasn't created until 1582!  The odds that dates created in the 2000's in the Gregorian calendar are interesting to computer software in 9999 are pretty low.

Comments

  • Anonymous
    June 14, 2016
    The words like "never" are quite strong when you deal with globalization in our world. Since it changes so unexpectedly, the "Calendar" concept may not be exist in 9999, who knows.