Hate leap seconds? Imagine a negative one

I was mostly talking about the slope of those charts: the line is still going upwards, but more slowly. The seasonal effects (the regular lumps) are large so it is hard to tell from the graphs what the long term trend is. My guesses are based on the IERS estimate for what happens after the detailed predictions in Bulletin A, and their charts don’t go that far into the future.

If it was going the same amount "faster", the slope upwards would be the same. But it's lessened significantly, even if it is still currently heading towards a negative leap second being necessary.

Strange is what they said just after the CCIR incepted leap seconds at the SI subcommittee in charge of the subject: "The CCIR may have overstepped its remit in defining the UTC" and "The process that led to UTC may have been illogical, but it was effective"

GPS satellite designers already have to account for clock skew due to relativistic effects. A nice little real world confirmation of the theory.

Luckily clock skew already happens and is handled more or less by the current systems. The difference between the system moving at relativistic speeds versus a crystal being slightly out of spec add up to the same result. Incorrect number of ticks for a given proper time interval.

That's part of the genius of Leslie Lamport, embracing the fact that your distributed clocks aren't consistent, so start looking at effects through distributed systems from a light cone perspective just like you do with relativity.

I'd like to think my descendants will be beet farmers in a far away solar system.

Those corrections (both special and general relativistic, with opposite signs) are already required to allow GPS to function.

We do: all these are taken into account for satellites. In particular GPS is one of the prime examples as it is affected by both special and general relativity and how fast time elapses is critical to its function.

Probably takes some serious skills to be an organic farmer on Ceres.

A collection of several falsehoods programmers believe lists, not just time:

https://github.com/kdeldycke/awesome-falsehood

Leap seconds are so much simpler than trying to wrangle two calendars with built in drift

When I first read this, my intial reaction was "LOL what a silly... of course the simple reason is..." ... and then it turns out, I couldn't actually explain it to myself. I had a couple of reasons lined up, but none of them passed muster when I broke it down.

I suspect the real reason my be overlapping domains of varying precision/accuracy, which tolerate different degrees of error on any specific time measurement, but still need to agree on a shared center of the distribution of that error.

So in our daily lives, we might tolerate a fraction of a second of drift without notice... But there are some specialty domains that do require more precision, and we need the time measurements in both domains to mostly line up, to avoid confusion. So our daily clock needs to be slaved to the more precise clock, even if we don't require that precision in most things.

Earth clock time and calendars arose specifically to measure time as concerns earth-related experiences --- events within a day, throughout the year, and across multiple years.

Measurement systems ultimately serve the needs of those who are doing the measuring. This fact alone accounts for many of the idiosyncratic aspects of traditional measurement systems. An acre-foot measurement (a volume of water) makes sense when you've got a pond whose surface area (in acres) is known, and whose depth (in feet) can be measured against a post or dam face. An acre itself is the amount of land a farmer can plough in a day (in German, Tagwerke), and would vary by terrain, farmer, plough, draught animals, and hitches.

Time systems suitable for other needs may come to be used. So long as a substantial human population remains on Earth, an Earth-centric time system will all but certainly exist, and adapt to changes in the Earth-Moon-Sun system's orbital and rvolutionary characteristics.

Look at how bad people are at dealing with timezones. Having two similar but subtly different overloadings of the same terms is a recipe for confusion (having very distinct terms would actually be an improvement).

> And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again.

There's also the exciting version where some of your time servers do it one way, and some do another; you could probably pick two traditional servers, and then one of each of the others and have a really terrible day. From experience with a setup where 4 servers were traditional and one was smeared, there was a lot of variation in time; but thankfully my systems weren't relying on time measured on different servers to be very consistent.

IMHO, leap smear probably should have been done with standard time on the wire, and the host agent doing the smear. But that would be more effort than doing it on the time servers, so there you go.

If I've learned one thing about dealing with exceptional events, it's that the less often they happen, the less likely you are to handle them well. Switching from leap seconds every few years to leap minutes every century, pretty much guarantees we'll screw it up. But maybe that's ok? Y2K was a fat nothingburger, after all the fuss.

> a leap hour in some far-off century

Just change your time zone offsets at that point, honestly.

It's not particularly interesting to be out of sync with the rest of the world, you always are and messages to/from external entities are even more so constantly. When it is interesting is when the thing you are doing is a function of time e.g. GPS or locked-step systems spanning geographic regions or so on. In almost all of those cases you're probably well used to dealing with time problems that are a bigger pain than a leap second. For those that aren't hiding the leap second and being off by slightly more than usual for a bit is probably better than hoping everyone can be prepared to suddenly care a lot about handling time oddities for one second every year (or century as you propose).

> A leap second is over in a second.

The problem isn't one where you hold your breath and squeeze your eyes shut for a second while the unpleasantness passes. The problem is when you have tons of code running and you don't know exactly how it'll deal with this very rare event.

If you're faced with an upcoming leap second there are various ways of dealing with it. One way is to do an audit of the code and hope that you can verify the most important parts. Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off.

There are other options, but I don't think there's an "obviously correct way".

Only a positive leap second is “over in a second”. A negative leap second is essentially “over before it starts”. This asymmetry is an opportunity for code to implement UTC incorrectly.

Another issue is that a positive leap second cannot be represented using time_t-like representations. But at least every time_t value maps to a UTC time.

By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun.

Yep, just use TAI, you're already converting time to show it locally, so no problem also including leap seconds in that conversion

Using TAI was also djb's solution to the problem. https://cr.yp.to/proto/utctai.html

> people expect noon to be "the time when the sun is at its highest point in the sky"

A) No they don't, which makes sense because

B) No it isn't

And "millennia later" is really overstating how soon this would happen. If you did this, every few millennia if people are very angry about it they would merely need to change their time zone definition one step. Now, how many millennia does it take to change time zone definitions where you live? Oh that's right they weren't even invented a thousand years ago.

So, firstly, people do not actually expect the sun to be "at the highest point in the sky" at 1200 local time, it hasn't been in their lived experience so why would they? They'd be surprised if it happened at 0800 or 1600, but precisely 1200 doesn't matter to them. Which is good because it isn't, it hardly could be.

Nobody was proposing to eliminate leap years (although perhaps renaming them "leap days" and marking them as a holiday might be better) which are a whole different problem.

Calculate how often leap hours will happen.

So, yes.

Time zone changes occasionally happen already.

I found this section very interesting:

> TAI is a statistical timescale which is produced at the BIPM by combining the reports from many atomic clocks around the world. Anyone who wants to find out what TAI it is now must mark the time with some local clock that contributes to TAI. Then some weeks after now when all clocks have been combined the difference between the local clock and TAI will be known. At that point it can be said what TAI it was at the moment of interest.

> There are several interesting features here. First of all, before 1977 the clocks contributing to TAI were not corrected for the gravitational redshift. Because most clocks are above sea level they tick faster than TAI should tick. Through the mid-1980s there is an annual wobble due to seasonal environmental changes at some of the clock sites. In 1995 a CCTF working group deemed that the clock frequencies should be corrected for thermal radiation, and the CIPM affirmed this in 1997. The steering of TAI to the corrected frequency occurred over three years from 1995 to 1998, and the final levelling of the curve over those years indicates that the frequency of TAI is now consistent with cesium atoms at 0 Kelvin.

Basically even with TAI there are all sorts of time deviations as an artifact of history.