Comment Re:Obligatory griping (Score 1) 209
True, but I would hope that future programmers would realize (somehow) that a year isn't exactly 365.25 days.
The programmer sees a discrepancy happening over a century into the future as "Somebody Else's Problem," and there would be little reason for users a century in the future to be aware of this presumption. Even if the users know about the proper algorithm, they may not know that the code they're relying on doesn't. Consider how long it was before Excel stopped rendering AD 1900 as bissextile.
Y2K, UNIX time overflow, etc. Only this time the original coders will be long dead. Best hope they commented better than they coded.
Correct. This calendar does not track the moon, or all seasons, it only tracks the year (n. winter solstice) and the day.
Keeping track of and predicting seasons is the entire point of a calendar.
+4Q probably shouldn't be used for businesses though which should probably just include 'minimonth' in the last quarter, but that's not in the scope of the terran computational algorithm.
A calendar that can't unambiguously reckon the Christmas shopping season doesn't seem to lend much utility to business.
Not exactly, if there isn't a TC designator appended to it, then it isn't a terran computational date.
Then you're seeking to have this implemented alongside the Gregorian Calendar (et al). Then what are you actually hoping to replace? Julian dates?
Ordinal numbering is not recommended for the terran computational calendar.
The attendant cultural shifts you're asking users to adopt alongside this system are steep barriers to entry that will not exactly aid adoption.