Leap seconds: Causing bugs even when they don’t happen

There is no problem with GPS time, only with converting from GPS time to POSIX time or some other leap-second affected time.

> The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well.

> Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account.

The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.

C++ is being adding basically both the kitchen and the sink for years now and still it hasn't broken anything. If anything, lots of warts have been removed now. This whole reasoning doesn't hold when the ISO C standard adds half-assed, optional rubbish to the C standard only to deprecate it the next release.

The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.

Rendering future times as local time already has a problem where the timezone (DST) could potentially change.

or…

if you want the future time stamp to be “exactly x seconds” in the future you can store a tuple of the TAI time stamp of when you create the data point, and the SI seconds into the future from that time and then render it as appropriate for the audience’s level of understanding

And if you want the future time stamp to be not actually a time stamp but a time of day on a calendar date, then you store a tuple of the TAI creation time, the UTC date you want it to be in the future

Because you can never ever be sure of the future, by keeping the time you make the assumptions you can at least either calculate the correct answer or fix the data later when you find out something has changed.

TAI is for timekeeping.

UTC is for calendars.

If you want an UTC time in the distant future, more than a few years away, then you cannot know how much time will pass until then.

The leap seconds are inserted randomly, you cannot predict when this will happen.

The UTC time is known only for the past, more precisely for the past 60 years.

For the future beyond a year, the UTC time is unknown.

On the other hand TAI, which is a real time, not a conventional quantity determined by political decisions, is known both for the past and for the future.

You are right that e.g. for scheduling meetings in the future, a different type must be used, whose meaning is "the time moment that will have this official name by then". This time should not be used for computing time differences with a resolution smaller than a day, before it becomes close enough to the present.

I like to think of it as UTC being off by 1s just before the leap second. :)

... I wouldn't call it an error? It's an offset between smeared UTC and non-smeared UTC, like between any two other time standards.

It's internally consistent, and for communicating with external entities that expect unsmeared UTC you convert as needed as much as possible. No different from if you were running TAI and communicating with unsmeared UTC, or communicating with TAI while running unsmeared UTC.

Right but as long as GPS satellites are synchronised with each other it doesn't matter all that much how synchronised they are with anyone on the ground, the position they return will still be correct.

Let's call the Google proposal UTC_smear. You can simply convert between UTC and UTC_smear and vice versa just fine. You just need to be extra careful to store each timestamp with their corresponding time format.

Just like you can convert between UTC, TAI and UT1.

> Kind of, but differences in time will forever deviate from the SI second so I don't think that really counts.

I don't follow. Outside of days with a leap second, you are using the SI second.

If you're measuring skew via raw-seconds-since-epoch or something similar, that's already an error-prone measurement. It's a non-goal for smeared UTC to be synchronized with TAI, just as it's a non-goal for unsmeared UTC to be synchronized with TAI.

+1, seems like leap seconds could be covered via a leap hour every 10k years or so. Implemented as a daylight savings change that gets skipped. Implement it at the level of time zones, which is complexity that we already have to deal with most of the time when we want to interface with humans.

Large parts of the world shift civil time by an hour twice a year. Drifting 1 day every 200,000 years doesn't sound like kicking the can down the road.

If human civilisation still exists by the time we've reached just 1 hour of difference we'll be occupying multiple bodies throughout the solar system, if not further afield, and have to have come up with a new time system anyway. Even the length of a second varies because of relativity.

In 100,000 years when 12pm is in the middle of the night, no one is going to care. It will have been that way for all of living memory, and the fact that noon used to be midday will be nothing more than a historical curiosity. The drift is far too slow for anyone to notice.

What about leap milliseconds? There are plenty of applications that need millisecond accuracy.

Out of interest, have you read https://qntm.org/abolish?

I personally tried this for a few weeks: I set my clocks to GMT, and converted everyone else's silly little timezones into one unambiguous number. All I accomplished was memorizing the offset between GMT and local time and getting marginally quicker at the required arithematic to convert between them. It didn't even solve any problems, because a) nobody else was doing it, so, shrug, and b) I immediately lost all context for the earth's rotation, and that turned out to be a massive pain in the ass. I think the very least we can do, though, is get rid of DST.

> we have digital aids for that

Like a clock that you can adjust so that 0:00 is the middle of the night?

We already have universal world-wide time: UTC and TAI. You can use these today, and nobody can stop you.

> It solves all timezone bs.

So when does Monday start? 14:00 UTC in your location?

> I'm all for a universal world-wide time. then we'd just have to learn what time is middle of the night for what location,

There is one thing that is highly inconvenient and to have day border during working hours.

Because you'd get up on Monday and then book a table for after work on Tuesday. The ambiguity of defining "today" would be problematic.

Now sure people who work night shifts have that, but it's a small number of people and a small number of services that are open 24/7.

Isn't 3:30pm in the middle of the night a regular occurence during parts of the year for people at certain lattitudes?

If the drift is 18s over 50 yrs then it doesn't address your issue to any noticable degree throughout your life.

Nor that of your children, grandchildren etc etc, as the change is gradual enough that nobody would notice. The only way to get a significant difference is by somehow sleeping for thousands of years (1k would be 6 minutes, which would still be impossible to tell with human senses).

It really is a pretty pointless solution to a non-existing problem.

I tend to agree. Let astronomers use a rotation-synchronized time. (Aren't they bothered by jumps anyway? They probably need a more gradual skew, which is to say, not SI seconds.) Let everyone else use TAI, and in a few millennia when high noon isn't noon anymore, we'll worry about it then.

Oh by the way, unless you live smack in the middle of a timezone, solar noon isn't clock noon anyway. Plus it gets all jacked up with daylight savings (which should also be abandoned), so the whole notion of leap seconds is farcical on its face.

You need to be able to do both!

Since the start of atomic time the day has generally been about 1ms longer than 24x60x60 seconds; at the time of the last leap second in 2016 it was 1.5ms longer. But since last year it has been slightly less than 24x60x60 seconds! For the last few months it has been around 0.25ms shorter.

Well either way would work I suppose, but yeah let's speed it up a bit. I propose we move the moon closer.

Exactly.

The position of the sun doesn't matter that much. Many locations already do daylight saving and would actually prefer to switch their clocks to "saving time", which moves the sun to a point that isn't highest at noon. (As if it actually mattered to keep the sun fixed.)

We can always calculate where the sun and stars were positioned if we care.

It shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity.

24 hour exchanges are hosed though

Where do you work now and what mistakes have they made? :P

That isn't at all how the ephemeris data is represented in GPS. The satellite locations/headings are specified in earth-fixed geocentric coordinates. So, it's as if the earth was sitting still and the satellites were swarming around it.

The effect of earths very slow changes in rotation speed would effect the accuracy, but the ephemeris data is periodically updated based on observations of satellite locations by ground stations, there are many larger sources of positioning error than changes in the earth's rotation. This is also why first fix from a cold (memory wiped or long offline) receiver takes a long time even when it knows your location, unless you have AGPS (e.g. via the cell network): it doesn't know what satellites are overhead and it has to do a brute force search before it can find the signals and download the ephemeris data.

(There is a side channel that carries info on leap seconds, so that civil timing stuff can derrive UTC from the GPS time. ... but that isn't used by GPS itself at all).

Here is a nice page that shows the current GPS time and notes that it does not include leap seconds: http://www.leapsecond.com/java/gpsclock.htm

On one side it might not be a good idea to have actual actionable and efficient criminal plans enacted in popular fiction.

On the other side, it seems to be a disservice to the community to have stupid ideas widely spread around. It's hard to balance for sure.

You should record the event time separately [1] from the beginning/end of the measurement period - the first as a time instant in UTC ('wall clock'), the latter as a difference between two values of a guaranteed monotonically increasing clock.

This is something you need to do regardless of leap seconds to handle things like NTP kicking in to adjust your local wall clock time.

[1] - Depending on the programming environment, these might be either different timestamp types recorded separately or converted appropriately to reflect different uses, or a smart combination type like time.Time in Go.

> Does that mean the government owes you the fine?

no it just means the fine is immediately overdue :)