Live data from Hacker News

Insane complexity of calendrically correct date and time operations

yourcalendricalfallacyis.com

51–60 of 146 posts

Re: Insane complexity of calendrically correct date and time operations

#51

I really dislike the tone these sort of things tend to take, which is “here’s some stuff you think but you’re wrong about.” The reason people get stuff like this wrong (and names, and addresses, and and and) is because it’s really hard to get right. And it’s added difficulty on top of writing code which is already pretty challenging.

Especially when it's all stuff that's already been covered in very similar essays.

Actually introducing good libraries and methods for handling these issues properly would be much more useful than a smug collection of fallacies and a tacked-on link to ICU at the end.

Re: Insane complexity of calendrically correct date and time operations

#53
post #9

This could very well have been called “ Falsehoods programmers believe about date and time calculations ”. It fits very well into the pattern of other similarly titled lists which have been published in recent years.

Those lists make a point of not backing up any claims made.

I much prefer this format.

Re: Insane complexity of calendrically correct date and time operations

#55
post #8
post #3

Earlier quoted context omitted.

No, because unix times can repeat in the case of leap-seconds (this is necessary to be able to represent future times correctly).

You can avoid repetitions by using clock_gettime(CLOCK_MONOTONIC, …).

But that's no longer Unix time, it's an arbitrary value that's usually something along the lines of "number of seconds that the CPU has been awake since boot".

Re: Insane complexity of calendrically correct date and time operations

#56

I've encountered just about every item on this list working on my Apple Watch complication, Better Day[1], which supports 11 calendar systems in 21 languages. The funny thing is, the last item on this list — always use ICU through the NSCalendar API — is the exact conclusion I arrived at, and one that I preach to anyone who will listen. Especially with modern Swift syntax, complex questions like "what's the current d…

I only skimmed your article, but are you sure that's right? There must have been at least several date adjustments before your app was release yet the system time maintained the correct date. Presumably it'll correct afterwards, invalidating the date offset.

Re: Insane complexity of calendrically correct date and time operations

#57
post #39

For quick scripts, I do all my date math with seconds-since-the-epoch, retrieved with "date", and then convert back at the end. The final date benefits from the latest timezone package update, so mostly I do OK.

This mostly work without problem for past time, but it can be wrong for future time, since timezone/DST may change. When you want 2pm next Sunday, you want 2pm next Sunday local time, not whatever 2pm next Sunday is supposed to be as of now.

Re: Insane complexity of calendrically correct date and time operations

#58

Imagine we did not have names for months and days. Would you call the tenth month October or December? It does not make sense. Then, the other months at the start of the calendar, would you name them after phases of a military campaign of preparation for war, conquering, looting and pillaging? Would that be deemed politically correct? On the weekday names we are not doing any better. Tuesday - named after the god of…

> As for the lengths of the months, imagine if you were trying to make the case for the different lengths of months and you were trying to get buy in from your friends in accounts. Surely they would want equal amounts of days in each quarter? Imagine trying to persuade them that different lengths were better, what plausible possible reason could there be?

The year is 365 + epsilon days long. The epsilon means we need to periodically add or remove days to synchronize solar time with the seasonal calendar; in the Gregorian calendar, we sprinkle 97 such days every 400 years. Armed with this complexity, you have several options:

1. Accept that a month is going to need an extra day about once every 4 years.

2. Have the extra day be not part of the regular cyclical rotation (i.e., be intercalated). This is probably even more complex for bookkeeping than option #1.

3. Insert an extra month's worth of days on a longer period of time (this is essentially what lunar calendars do, but the effect of leap days themselves are less noticeable since the lunar month is quite out of whack with the solar calendar).

As for months themselves, you run into the problem that 365 and 366 are not amenable for evenly dividing the year into months: their factors are 5×73 and 2×3×61, respectively. 360 is much nicer (2³×3²×5, i.e., is divisible by every number between 2 and 10 but 7); unsurprisingly, a few cultures opted to use 360 as their basis for month divisions. The Mesoamericans used a calendar that was 18 months of 20 days, with 5 extra days that were intercalated.

As it turns out, the lunar month is about 29.5 days long, and the moon is a very obvious cyclical timekeeper (much more obvious than keeping track of days than the sun's seasonal positioning changes). Using a lunar month is going to give you a natural 29/30 alternating month period. However, you end up short by around 11 days when you do this. If you sprinkle them around the months, you find yourself naturally having 7 months of 30 days and 5 months of 31 days.

In terms of calendrical complexity, no one beats the Mayans. They opted for a calendar that has three different lengths of the year: a ceremonial calendar that counts 13 months of 20 days, a solar calendar that is 18 months of 20 days with a 19th month of 5 days, another calendar for long-term record keeping that counts from an epoch in base-20, except that one digit is base-18 instead (for a "year" of 360 days). On top of this, they have a "week" of 9 days, and they counted the current day of the lunar cycle, the current lunar cycle number, and whether the current lunar cycle was 29 or 30 days long. And there's another 819-day cycle that we still don't know what it corresponds to. Oh, and you count months and days like "January 1, February 2, March 3, ..., December 12, January 13, February 14, July 31, August 1, ..."

Re: Insane complexity of calendrically correct date and time operations

#59

I really dislike the tone these sort of things tend to take, which is “here’s some stuff you think but you’re wrong about.” The reason people get stuff like this wrong (and names, and addresses, and and and) is because it’s really hard to get right. And it’s added difficulty on top of writing code which is already pretty challenging.

Especially when it's all stuff that's already been covered in very similar essays. Actually introducing good libraries and methods for handling these issues properly would be much more useful than a smug collection of fallacies and a tacked-on link to ICU at the end.

I don’t understand this objection.. the method to handle these issues is to use ICU / NSCalendar.

Re: Insane complexity of calendrically correct date and time operations

#60
post #47

The leap second has a history of breaking computers. Pretty much every Linux server running Java broke in 2012, for example. 2009 saw a bunch of Linux kernels crashing in logging code. 2016 was mostly better except for Cloudflare: their systems had an assumption time never runs backwards. https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

There's now "Google time".[1] This handles by leap seconds by making each second slightly longer, starting 12 hours before the leap second and ending 12 hours after it. [1] https://developers.google.com/time/smear

While I wouldn't want to be the one responsible for designing, testing, implementing and converting to using said system, it does seem like the easiest way to handle the problem for the majority of cases in this day and age, where measuring 1/86,400th of a second is trivial. If only we were deciding how to implement leap seconds for the first time right now...
Post reply on HN