Leap second hiatus

As long as everyone agrees on the time GPS will work. It's a question of how much deviance from solar time we are willing to tolerate vs how much effort we want to tolerate.

GPS does not use leap seconds. See e.g. https://en.wikipedia.org/wiki/Global_Positioning_System#Leap...

Leap seconds have nothing to do with precision time. It's a non-periodic alteration to the definition of UTC. Those niche applications that require second-accurate knowledge of Earth's rotational accuracy don't need to rely on leap second changes to UTC; they could get that information out of band, and will need to anyway when they need sub-second accuracy. The 99.999% of other applications that don't need to know Earth's rotation orientation relative to the sun within a second -- but do have to calculate time differences between two UTC times -- would be much better off not having to deal with leap seconds. Leap seconds were a terribly misguided idea.

Precision isn't a binary, it's a continuum. The question at hand is whether there are significant use cases where 1 second of slack in matching the Earth's rotation is acceptable, but 30 seconds is too much.

GPS isn't an example of that because 1 second is already a quarter mile off.

GPS time is already immune from leap seconds. It has a fixed offset from TAI of 19 seconds and always will.

It also contains UTC offset information so that you can derive the current UTC time from GPS if you wanted to.

> I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.

The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes.

We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after the leap hour (hereafter UTC'). After the leap hour UTC and UTC' will coexist, where UTC' = UTC-1. Since time zone definitions themselves have UTC offsets, the trick is that instead of replacing all occurrences of UTC with UTC' (so that they would have UTC' offsets) we replace those offsets to have the same net effect. For example EST is UTC-5 before the leap hour and UTC'-5 = UTC-6 after the leap hour, so we pretend that the definition of EST changed to UTC-6.

Note that this approach essentially fixes the UTC-TAI offset (as opposed to the UTC'-TAI offset) and makes UNIX timestamp (time_t) deviate from the current version of UTC (well, UTC'). I believe this is just a matter of definition and thus much doable than changing UTC every few year. After all, leap hours would be much rare, probably the first one would occur at least a few centuries later.

I don't see a single thing different between leap hour and DST switch. Especially since Europe wants to cancel DST it wont even be something which happens periodically forever

"If it hurts, do it more often" — Martin Fowler

> Besides the sibling comment that some things rely on the days being synced to rotation

Examples would be great. Especially examples of things relying civil time to track rotation.

> doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built.

tzdata updates happen all the time (in a relative sense). So code would need to handle those, and I don't see why potential leap hours couldn't be handled like that. Just means that Europe/London eventually will be +01:00 (or is it -01:00, anyways) instead of +00:00 its now.

> However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.

You are asserting that without any justification. I see no benefits and lots of downsides in having leap seconds in civil time specifically.

No, they can't.

Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed.

If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't. By historical happenstance, they have been put in charge of time, and it is truly a question of the tail wagging the dog when they care about a 1 second deviation between UTC and the position of the sun at a particular longitude.

Remember that your code needs to account for the possibility of a negative leap second, meaning if you're using epoch time for timestamps you could have an instance that an event that happened after a previous one could be stamped as having happened before it instead.

https://en.wikipedia.org/wiki/Leap_second

Edit: Actually I was slightly wrong, in the event of a leap second, we would repeat the same second twice.

You know in some places they will forget the conversion so you'll have weird cases that are off by 37 seconds.

No, using TAI is simpler, because it is really the time that has passed since some origin. Therefore any operation performed with its values behaves as expected.

Neither UTC nor local times are times in the physical sense. At most you can say that they are times passed from a non-constant origin of time, which changes frequently and in an unpredictable mode for the future.

People always forget what UTC and local times really are and they very frequently make mistakes in their handling, especially for future events.

The foolproof way, as advocated by Bernstein and others, is to use only TAI for internal timekeeping and computation, and to convert to UTC or local times only the values that will be seen by human eyes.

I have done like this since many years ago, and it was always simpler for me. It would have been much simpler if this would have been a general practice, as that would have eliminated the useless conversions required for communication with other systems that use UTC, e.g. when using NTP.

Using TAI is simpler because:

* Many apps can get away with only using TAI, so they don't necessarily have to track the difference between UTC and TAI

* If your system uses TAI in its distributed coordination mechanisms, you don't need to worry about leap seconds and an error in the UTC-TAI difference won't cause your system to fail

> The acronym TAI refers to International Atomic Time.

Good one. Wikipedia[0] is more helpful and states it comes from "temps atomique international" which is french.

[0]: https://en.wikipedia.org/wiki/International_Atomic_Time

I don't think nuclear explosions belong in that list. They have tremendous power, but very limited energy on a planetary scale. Do you have a source that says otherwise?

> change in the angular momentum carried by oceans and atmosphere

...and some liquid (or at least semi-liquid) stuff beneath the crust?

Right.

But tidal forces are not completely irrelevant to leap seconds.

The length of the atomic SI second was calibrated to match the previous sidereal second, which was based on the length of a year. In practical terms, the sidereal second was based on Newcomb’s Tables of the Sun, which was a model of the solar system developed at the end of the 1800s based on historical astronomical observations https://en.wikipedia.org/wiki/Newcomb%27s_Tables_of_the_Sun

So the length of the second is based on the length of the year 1900, and derived from older astronomical measurements of the rate of movement of bodies in the solar system.

Leap seconds exist because by the 1960s the length of day no longer matched Newcomb’s calculations for 1900: it was longer by 1 or 2 milliseconds.

Is the total mass of all mined minerals and hydrocarbons more than rounding error in the calculation of moment of inertia?

This would assume that mined materials stay at a higher elevation than they were. And that the materials above those items didn't collapse down and/or aren't heavier than the mined mass.

Slowing down of the earth is caused by wind turbines, just as extracting energy from the tides causes the moon to fall towards the earth. When the earth will have completely stopped rotating, and the moon be dangerous close to the earth, that will be yet another shitshow. And they call this "renewable energy"?

P.S.: not serious

Technically, that was a Linux kernel bug that Java happened to be heavily affected by: https://news.ycombinator.com/item?id=4188412

Those algorithms should be using TAI, not UTC.

Any distributed system that breaks in the presence of leap seconds is necessarily poorly designed.

The fact that any non-UI code uses any time standard except TAI is a very unfortunate historical mistake that will hopefully be cleaned up over the next few years.

Thankfully since 2013, Linux kernel has supported TAI.

> Having lived through systems going backwards some 17 seconds due to a botched NTP-GPS appliance config

Well then, it really was botched. I was running an off-line hodge podge of 50 or so RH7.3 + Win2K systems back in 2002, where I had to manually fix the few second drift every couple of months, and the RH machines all slewed faster/slower to adapt, non ever went backward or jumped forward (Don't remember how the Win2K handled it; They weren't mission critical and I didn't care much).

>'From the perspective of the typical time_t rendering of Unix time, there is no way to uniquely represent that 61st second. It just "disappears".'

This is a great and really intuitive summary of the problem. Is there a certain class of problem related to disappearing second? Like are these more likely to be filesystem issues or things that rely on timestamps? Or are there second order problems as well?

>"I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid. I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid."

Sorry if this is a silly question but was that check simply that "time t1 is greater than time t0"? Also was the duration of that outage(17 seconds) or would this have been equally catastrophic at a single second?

Yes, the satellites should know 6mo in advance. UTC is still a head ache though.

phew!

Now this is going to sound crazy but what if we just extend the year by a few seconds by default? Then we can just skip seconds as needed.