Insane complexity of calendrically correct date and time operations
yourcalendricalfallacyis.com
yourcalendricalfallacyis.com
Especially with modern Swift syntax, complex questions like "what's the current day of the year" end up having simple, almost poetic answers like "calendar.ordinality(of: .day, in: .year, for: date)". And you can trust that they are correct for every calendar and every locale. Usually. [2]
[1] https://itunes.apple.com/us/app/better-day-a-complication/id...
[2] https://www.joeycastillo.com/notes/2016/09/18/of-crescent-mo...
Future months are still totally fine; the date offset is just a temporary fix that the user remembers to turn on when the announcement is made, and to turn off at the end of the month.
https://developers.google.com/time/smear
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-co...
The smear technique results in seconds that are 11.6μs longer than nominal, and Google makes the case this is within the "manufacturing and thermal errors of most machines' quartz oscillators". So at face value, I'd say software already copes with discrepancies of that order.
However I would infer the maximum delta actually seen by an NTP client is larger and depends on the client's polling interval. e.g. If a machine runs a normal clock locally and synchronizes every 20 minutes (which is probably on the high side), it would see about a 14ms jump on each sync during the 24 hour smear window.
That's assuming the NTP client doesn't already use a smear algorithm locally to correct for drift (Windows doesn't, but I think Red Hat Linux might? Per https://access.redhat.com/solutions/39194 "NTP polling does not directly synchronize the local system clock to the server clock; rather, a complex algorithm calculates an adjustment value for each tick of the local system clock")
Maybe someone more well-versed can elaborate further.
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-se...
(btw, the word "bigotry" has a real meaning and this isn't it.)
That's fine as far as it goes, but make sure never to use a BSD machine as an NTP server or you will cause a lot of confusion for any servers downstream.
But a more important distinction than whether you smear over +/-12 hours or +/-1000 seconds is whether you broadcast a bogus time signal to all your hapless servers, which is what Google does, I think, or whether you fix your kernel and C library so that the system knows the real time but reports UTC-SLS to those programs which use the old APIs and are therefore presumed to be incapable of understanding the real time. For example, clock_gettime(CLOCK_REALTIME, &res) might provide UTC-SLS (or whatever) for naive programs while the same syscall with CLOCK_TAI or CLOCK_UTC might give you the actual real time correctly.
edit: which cites https://infiniteundo.com/post/25326999628/falsehoods-program... (from HN's own patio11) as inspiration, as the original "Falsehoods programmers believe about X".
I much prefer this format.
Calendars almost never have crazy holes in the middle of them. When you say "I'm in Chicago", you pretty much can schedule an appointment at 1 or 2pm on "Sunday" or "9/20" or "next Wednesday" and everybody knows when that will happen. Leap years cause a little bit of trouble.
Where it gets tricky is when you have to interact with wall clock times, say, calculating the number of hours until your calendar event happens, or looking for all the events in a given range of wall clock dates. This is the world of timestamps, offsets, and "the global timeline" that everyone in the world experiences together.
Calendars also don't really care about daylight saving time.
If you keep these two separate and are specific about which you're dealing with, 90% of this goes away. Separate calendar from arithmetic/wall clock times. Not all will disappear, but a surprisingly large amount.
Source: working on https://www.interval.org/ and using the excellent NodaTime library. Thank you, Jon Skeet.
The comment right above yours at the moment talks about effectively that very problem (in this case, an unforeseen date moving a calendar back a day).
A fantastic overview of the headaches you'd have if you wanted to code all this.
Wow. I live in Europe, and find it weird that people can consider the week to start on Sunday.
I guess everything that may appear normal within a cultural frame of reference can be off in another, even the most basic of things!
For instance, if I were to tell you "Beginning of next week, I'm gonna X", you'd understand Monday, correct?
I'd likely understand it as Monday in other contexts too, because it's very rare for something to start on Sunday. Monday and Saturday are the transition points and thus the logical places to start doing something.
But I might understand it as Sunday if context seemed to point that way. What I'm saying is that nothing is organized according to "the beginning of the week", so the question of which day is the beginning of the week doesn't have any implications.
Why would this be unusual? I'd expect pay-by-the-week to be more common for part-time employees, but it's not rare for FTEs either.
I found the original article a bit strange in it's partitioning of the world into { US, Europe, some places }, I feel that is giving ... undue weight to the US convention, but I haven't studied this to see if I'm right.
I question whether "Thursday of week 37" is really that much clearer than "Thursday, September 13".
It never occurred to me to check my Apple Watch for a week number complication. A bit disappointed it's not there, even if I'd never use it.
Update: you can install an app to Apple Watch that supplies a complication for it. "Current Week".
And sometimes you really want to speak about the entire week without naming a day ("we'll have the first boards week 40, smoke-test and bring-up during week 41, and then start proper development by week 42"), since it's times in the future and you don't want to be too specific but still align work tasks with weeks.
Also (re: a sibling comment) Google Calendar shows week numbers, or can be configured to. For quickly finding out the week number, there's always https://vecka.nu. :)
KDE and i3 desktops can be configured for pretty much arbitrary date formats, I always have the KW in there.
You are almost certainly neither Portuguese nor Maltese.
In these two European languages, the days of the week are literally numbered as if Sunday were the first day of the week.
Portuguese: Monday is "segunda-feira" which means something like "second market day" Maltese: Monday is "it-Tnejn", which AFAICT means "the second [day]"
In both languages, most of the other days have similar names, representing their position in a week that starts on Sunday.
Netherlands reporting in. My parents always taught me that the week starts on Sunday.
So Sunday, the first day of the week, is still part of what's called the weekend, right?
> So Sunday, the first day of the week, is still part of what's called the weekend, right?
I've always interpreted "the weekend" as a shortening of "the weekends." Sunday is at one "end" of the week and Saturday is at the other "end." Sort of like a if you hold a stick out, there's a "near end" and "far end."
For countries with these as official religions you will find that offically Sunday is still the first day of the week for many purposes. For example: In the U.K., officially still Protestant, a week for the purposes of statutory sick/maternity/paternity pay or national insurance begins on a Sunday. Sunday trading legislation was talking about weeks commencing on Sunday as recently as 1950.
* http://www.legislation.gov.uk/uksi/2014/1640/article/2/made
* http://www.legislation.gov.uk/ukpga/Geo6/14/28/section/22/en...
If you think that millennia-old traditions, which you can still find observed in Europe if you look, are weird then academic weeks beginning at noon on Wednesday, examples of which can also be found in both the U.S. and Europe, will probably blow your mind.
If we go on a far enough time scale, all calendars are constructed abstractions so theoretically nothing about them is true, but I'm not sure what's the point of that.
Properly supporting calendrical calculations serves two major purposes:
1. Serve the billions of people who don't use the Gregorian calendar or who live in areas that don't match your idea of time zones.
2. Functions as a human form of "platform independence". Properly handling dates/times quickly exposes places you've made silly assumptions or accidentally broken things. This protects you from actual bugs and ensures you avoid whatever the future version of the Y2K problem is. Such bugs are always easier to fix when you have a smaller database and fewer users.*
* In general bugs and breaking changes _never_ get easier. Every day you delay increases the pain imposed on future you and users. Obviously there is a balance - a startup needs to worry about getting to "default alive" first and foremost - but don't delay too long and where it doesn't impose an inordinate cost do it right the first time.
There isn't that much use of non-Gregorian calendars in software, even in places that do make use of them. And if you do support them, it's another source of bugs, as you have to deal with new Japanese era names and the like: https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-jap...
https://calendars.wikia.com/wiki/6*6*10_regular_calendar
It was my fantasy escape from the crazy irregularities of the Gregorian calendar.
Unfortunately they failed to come to consensus between different calendar designs :(
https://en.wikipedia.org/wiki/George_Eastman
https://en.wikipedia.org/wiki/Moses_B._Cotsworth
https://en.wikipedia.org/wiki/International_Fixed_Calendar
https://en.wikipedia.org/wiki/International_Fixed_Calendar_L...
https://gizmodo.com/how-the-quest-for-a-perfectly-rational-c...
This isn't specific to Los Angeles, right? It's just referring to the fact that anyone with a negative UTC offset would see an epoch date of Dec 31, 1969 in their local time (I hope).
This reminds me of an anecdote from a talk on timezones. Shortly after Stephen Hawking died, the the Google search snippet for "When did Stephen Hawking die" said "Tomorrow" for people in the US.
It was pulling the date from Wikipedia, but it was still the previous day in the US.
I have implemented a large application which does a lot of time calculations, and run onto most of the issues listed in the article, except that I didn't use hewbrew calendars :).
E.g. I am in Vietnam. I make a dentist appointment for when I am back in the US at 2 pm. I put the appointment on the calendar. I get to the US on the day and find the appointment is at 1 am the day before. Worse still, is in the opposite direction because I wont get the alarm until the event has passed by 11 hours.
Stop being clever google. If I put an event in my calendar for 2pm, just leave it there. Yes, yes, I could hunt down the timezone menu item every time. Better yet, I finally get around to transitioning out of that terrible company’s services.
There's been talk of setting UTC=TAI for quite a long time and I think it'd make sense. It'd take so long for TAI to drift from the actual rising and setting of the sun that we'd probably all have standardised on Swatch Beats by then anyway.
As an expert (as far as anyone around here is), what would your pick be for common civil time? Personally I feel like "precise time and simplicity" is almost obvious choice, but apparently it is not quite that clear cut.
Civil time has to stay in phase with the sun. As I see it, that's not negotiable. Inserting leap seconds, so that the nanosecond field of UTC remains the same as the nanosecond field of TAI, and the jumps that occur are negligible for ordinary people, seems to me overall the simplest solution, though I can see that UTC-SLS would be simpler for some people in some situations, and switching to leap minutes or leap hours would be simpler for people living now, who could then just ignore the problem. (Pollution and global warming and lots of other things can be treated in the same way, of course. Perhaps some of these things really will be easier to solve in the future, but I'd rather not rely on it.)
I used simplicity in the meaning provided by link in parent comment refering to three desirable properties of time systems: "Every "day" has 86400 "seconds" (606024)."
> Civil time has to stay in phase with the sun. As I see it, that's not negotiable.
I don't see why that needs to be the case on a seconds level.
> switching to leap minutes or leap hours would be simpler for people living now, who could then just ignore the problem. (Pollution and global warming and lots of other things can be treated in the same way, of course. Perhaps some of these things really will be easier to solve in the future, but I'd rather not rely on it.)
Considering that need for leap hour would appear in over 500 years, I feel like trying predict the situation then is really borderline overarrogant.
Also leap hour would be basically a timezone shift, and I bet we will be doing timezone changes anyways in the next 500 years
With a timezone shift, all that happens is that "09:00:00 +0900" is the same as "10:00:00 +1000". We can cope with that. But if you make UTC jump back an hour, then we have "09:59:59 +1000" followed by "09:00:00 +1000", and then the whole previous hour happens again. The internal timestamps in computer systems (typically expressed as a number of seconds since some epoch) repeat themselves for an hour. Causality is violated. Most computers stop working. You would probably have to switch them off beforehand to prevent data loss and even longer interruptions to service. You could shut down all the servers and desktop machines, stop all public transport and so on, but you can't just turn off the computers in embedded systems and satellites and so on...
So let's not try to arrogantly predict the situation in 500 years. Let's carry on with the established system of leap seconds, at least until someone comes up with a sensible alternative. Then there won't be a "situation" in (less than) 500 years.
As Albert said: Time is what clock measure. The more you dig into it, the more you realize how true that is!
Lets propose a new time format we could count the number of exoseconds since the beginning of the universe. Then convert that number to whatever native time format we want. Store that as a number and use that for conversion. Age of universe 4.415×10^17 seconds, 4.415×10^26 exoseconds
This left out the Long Now Foundation's advocacy for five-digit years to deal premptively with the Y10K bug. And, less tongue-in-cheek, to promote a view of time that is not conventional in this day and age.
> False. Weeks start on Sunday in the United States, Monday in Europe, and a couple of places start on Saturday.
In some countries weeks start on Mondays.
> All the important years are four digits long
> False. It’s the year Heisei 30 in the Japanese calendar.
Or 13.0.5.15.0 in the Maya calendar.
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.
Knowing it’s complex, the next step is to get help, not hack up your own solution.
I liked the tone... sort of a “can you believe this?!”
On the weekday names we are not doing any better. Tuesday - named after the god of war? Doesn't make sense to me.
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?
We learn the names of days and months by rote at a very young age. We get encultured into accepting the status quo and never questioning little details - nobody asks at school why 'Dec'-ember is month twelve.
Do you have a reference for this? Besides Mars how are the others related? And also that would make a lot of sense to name periods of time after what you are doing during that time.
Edit:
Also, I remember reading that the one thing the pharaohs of ancient egypt had to pledge before taking power was not to change the calendar again. Since changing it according to whatever current whims caused even more chaos. At some point the "deep state" of the time just wouldn't stand for it anymore.
Edit2:
Found the ref. Actually I mentioned it here a few years ago:
"It must have been, then, that there were local attempts to retain the coincidences between the true and the calendar year — intercalation of days or even of months being introduced, now in one place, now in another ; and these attempts, of course, would make confusion worse confounded^ as the months might vary with tlie district, and not with the time of year.
That this is what really happened is, no doubt, tlie origin of the stringent oath required of the Pharaohs in after times, to which I shall subsequently refer.
[...]
When the year of 365 days was established, it was evidently imagined that finality had been reached ; and, mindful of the confusion which, as we have shown, must have resulted from the attempt to keep up a year of 360 days by intercalations, each Egyptian king, on his accession to the throne, bound himself by oath before the priest of Isis, in the temple of Ptah at Memphis, not to intercalate either days or months, but to retain the year of 365 days as established by the Antiqui.^ The text of the Latin translation preserved by Nigidius Figulus cannot be accurately restored; only thus much can be seen with certainty.
To retain this year of 365 days, then, became the first law for the king, and, indeed, the Pharaohs thenceforth throughout the Avhole course of Egyptian history adhered to it, in spite of their being subsequently convinced, as we shall see, of its inadequacy." https://archive.org/stream/dawnastronomyas00lockgoog/dawnast... https://news.ycombinator.com/item?id=11017726#11020076
https://en.wikipedia.org/wiki/Japanese_calendar#Months
https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#...
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, ..."