Is it true that Unix time is as simple as it seems? Is there exactly one second between adjacent integers? Do all Unix time values occur only once simultaneously around the world?
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".
The one mistake with UNIX is that UTC is used. It should have been TAI, and leap second adjustment should have been handled by the timezone package (but at the time people weren't worried about leap seconds, so it's understandable). As it is, the system clock has to change. This is as bad as MSDOS time (and other systems which put localtime into the actual RTC). Using UTC as the time reference, independent of local time, was nearly genius. With TAI it would have been pure genious. No, wait, using an epoch time of the Big Bang, and step size Planck time, now that would have been pure genious. It doesn't take as many bits as you may think..
Civil timekeeping is based on UTC because we want clocks and calendars to remain synchronised with the sun. It's not just astronomers who care about whether the sun is above the horizon. If you think about it, the solar day is the one unit of time that almost everybody cares about and pays attention to. If you screw up the day, you also screw up the week and anything else that is based on counting days. Why would you want to do that?
But offset of UTC for TAI is like 37 seconds or something poxy like that. Nobody cares about this, the sun moves too slowly for that to make any difference.
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.
Yes, the difference is 37 seconds now, but it's growing quadratically. It's quite possible that we'll change the way we express times and dates, but it's almost certain that we'll want them to stay in phase with the sun, and we'll probably want to stick with the SI second and with something like TAI. My guess is we'll continue to want a simple relationship between TAI (or its successor) and the civil clock time, something like the current relationship according to which they are a whole number of seconds apart. That implies that we'll need something like leap seconds (or leap minutes perhaps). There doesn't seem to be a reasonable alternative.
I feel like throwing in a leap hour (basically tz shift) once in a millenia would be more reasonable solution, if for nothing else than letting future generations deal with it instead of trying to futilely pre-empt problems that are not really problems yet.
The length of the day is increasing roughly linearly at roughly 2 ms (per day) per century, because of tidal effects. The difference between TAI and UT1 is the integral of that, so grows quadratically. If we assume that the mean solar day was "correct" around 1900, then a hypothetical atomic clock that was synchronised to the sun around 1900 is, after x centuries, out by about 36525.x^2 ms. TAI was in fact synchronised to UTC around 1960, when atomic clocks were widely used, and the slowing down of the Earth's rotation is rather unpredictable in the short term (decades), perhaps being affected by climate change, so the numbers are all imprecise, but the long-term (centuries, millennia) quadratic growth of the TAI-UT1 difference is inevitable.
Yes, roughly quadratic increase of LOD over the long term, but over short term more like a random walk. Right now the earth's crust is rotating faster than it did a century ago because things have speeded up. For a view over 2 millennia see plots of LOD at https://www.ucolick.org/~sla/leapsecs/dutc.html
In 1950 astronomers pointed out that there would have to be two kinds of time, one to agree with calendar days and one to be as uniform as possible. Arguments over subsequent decades inexplicably decided that there could only be one kind of time specified by international agreements, and we ended up with a choice of two out of three characteristics in what we now call UTC. https://www.ucolick.org/~sla/leapsecs/picktwo.html
You website is a true hidden gold nugget, thanks for putting in the time to write all that up.
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.
"Simplicity" is rather subjective, even if you answer the question: simple for who?
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.)
> "Simplicity" is rather subjective, even if you answer the question: simple for who?
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
Not at all. Just because it involves an "hour", rather than a "second", doesn't mean that it resembles a "timezone shift". It's totally different.
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.
Unix time depends on the wall clock time, so it is a wall clock time, so it can jump around arbitrarily when the computer clock is adjusted, and its seconds can be stretched as needed for gliding adjustments. Applications need to cope with that.
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.
> 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.
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...
That was my thought reading this list too. I am sure every calendar system will have a list of calendrical fallacies like this. But if you do decide to support the Hebrew calendar, you will not get “The current year is 2018” wrong. Or the number of digits in a year, if you choose to support the Japanese calendar. Actual fallacies in those systems will be less obvious.
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.
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 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.
>"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?"
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.
Yeah, the dude changed the definition of where the new year starts, moving it back two months. It's still arbitrary, it should have been at the (slightly fuzzy) winter solstice..
> 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, ..."
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...
Imho that's no better. A leap second "smears" the day lengths. Smearing the leap second means introducing changes at some scale, eg. more or less micro- or nanoseconds. Software needs ro be able to cope with this.
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.
Not wanting to be a complete BSD bigot, I can't actually remember if this broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD don't help (oh, for a time machine) but go to "you can test what we do" which is good.
Not to jump on the bigotry, but two of the three bugs mentioned in that comment were in proprietary software (Java and RRDNS) that merely runs on Linux. The hrtimer issue in 2012 was a real kernel bug though.
The 2012 bug was a bad interaction between Java and thread locking in the Linux kernel. It affected MySQL as well. The 2009 bug was in the Linux kernel, in the logging code. The 2016 bug I mentioned was in Cloudflare's proprietary code and only had a big impact because so many websites use Cloudflare. There are zillions of other smaller leap second related bugs, these are only three of the most visible.
(btw, the word "bigotry" has a real meaning and this isn't it.)
BSD is actually worse, it doesn't handle leap seconds at all, it simply ignores their existence and assumes the clock was simply inaccurate.
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.
I don't know about OpenBSD or NetBSD but I've witnessed FreeBSD handling leap second correctly. I also witnessed OpenNTPD ignoring it and that's documented, so I suspect OpenBSD doesn't handle leap seconds at all.
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.
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...
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.
Old APIs won't be the only problems, it's easy to introduce bugs like this new API or not (it's much easier to say use monotonic timers these days, but it's still easy for devs not to use th=em)
Don't let that answer confuse you. It seems to be phrased in an intentionally confusing way, but it's really only talking about time zones. At midnight 1970-01-01 UTC, Los Angeles, North America, and roughly half of the world still had their calendars on the previous day, because they have a negative time zone offset (Los Angeles was UTC-8:00).
Just learned google calendar uses the timezone your currently in by default even if you set the location back to your home. When I got back from travel, the notification was decidedly off. :)
Google’s “helpful” treatment of time zones decidely isn’t. I wish there was a way to tell google calendar to ifnore timezones altogether.
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.
"False. The UNIX epoch is January 1, 1970 in UTC, but is Dec 31, 1969 in Los Angeles."
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).
One related wrinkle that can catch out UK people (who tend to conflate local non-summer-time with UTC) is that the epoch is not midnight 1 Jan 1970 in UK time -- we were in the middle of a "UK time is GMT+1 all year round" experiment in 1970...
Hm. No. The UNIX epoch is in UTC, so it's always January 1, 1970. The tick (at this moment: 1537511644) is always relative to January 1, 1970. The timezone (TZ) only comes into it when that epoch time is translated to a local time with 'date' and other tools.
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'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 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]
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.
The thing to keep in mind is that before the sighting, the months are pre-calculated for when the first crescent moon should rise over Mecca. So a change only affects the single month where the observation differed. For example, if you're expecting to see the first crescent moons on October 10, November 9 and December 8, but you didn't see the first one until October 11, that doesn't push the moon sightings out for the rest of the year. It just means that the month you thought would end on October 9 will have an extra day, and the month you thought would start on October 10 will start a day later (and as a result will be a day shorter).
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.
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.
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.
This is actually a lot simpler than it looks. There are two concepts.
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.
From the list: All the important years are four digits long
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.
145 comments
[ 2.7 ms ] story [ 192 ms ] thread[1] https://en.wikipedia.org/wiki/International_Atomic_Time
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.
* https://unix.stackexchange.com/a/327403/5132
A fantastic overview of the headaches you'd have if you wanted to code all this.
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://github.com/kdeldycke/awesome-falsehood
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.
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, ..."
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.
[1] https://developers.google.com/time/smear
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.
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.
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.
https://greenwichmeantime.com/info/oxford/
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.
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?!”
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).
https://news.ycombinator.com/item?id=18036403
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.
https://calendars.wikia.com/wiki/6*6*10_regular_calendar
It was my fantasy escape from the crazy irregularities of the Gregorian calendar.