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.
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.
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
I think infinity is a more intuitive result, but most of the time i get this as a user i would rather see 0 (bought books per month: Infinity). As a programmer i like to get an error, because i forgot to handle an edge case...
Looks like the standard rails mess :/ Don't get me wrong. From time to time i am going to look at other peoples rails code to learn, how they solved common problems in grown rails apps. Most oft the time i leave rather disappointed...
Can you be more specific? The modeling/models don't look TOO insane - need some refactoring, but not too far off.
If you think this is a rails mess - you haven't seen anything yet. I am still able to hop in and reason about what this codebase does with no onboarding - a key benefit of rails. I've worked on codebases where all those niceties were thrown out the window.
--allow-unrelated-histories
By default, git merge command refuses to merge histories
that do not share a common ancestor. This option can be
used to override this safety when merging histories of
two projects that started their lives independently. As
that is a very rare occasion, no configuration variable
to enable this by default exists and will not be added.
I have used this many times while taking the opportunity to reorganise repos while migrating earlier version control systems to Git. I still need a crib sheet every time tho’!
See: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...