Hacker News Reader

Comment by denton-scratch | Hacker News Reader

If they do "abolish" leap-seconds, they have to "abolish" UTC as well, because UTC is defined based on leap-seconds. Any new timescale without leap-seconds needs a new name. Otherwise you get the same problem we made with GMT: "Do you mean 14:03 UTC before 2035, or 14:03 UTC after 2035?"

So lets call the new timescale NTS. Lots of records and timestamps have been made using UTC. So now we'll need a way of converting timestamps between UTC and NTS. We already have future timestamps in UTC; e.g. "This record must be destroyed at midnight UTC, Jan 1 2036". So even after we've switched to NTS, we'll still need to calculate UTC, so we'll still need leap-second announcements.

Timescales are a deep mess, and as the author notes, having them managed by a bunch of treaty organizations is nuts; treaty organizations are inherently political (and they move like molasses in winter).

View on HN

> If they do "abolish" leap-seconds, they have to "abolish" UTC as well, because UTC is defined based on leap-seconds. Any new timescale without leap-seconds needs a new name. Otherwise you get the same problem we made with GMT: "Do you mean 14:03 UTC before 2035, or 14:03 UTC after 2035

If they just stopped adding leap seconds to UTC at some point, why would there be any ambiguity about the definition of any given UTC time?

> So lets call the new timescale NTS. Lots of records and timestamps have been made using UTC. So now we'll need a way of converting timestamps between UTC and NTS. We already have future timestamps in UTC; e.g. "This record must be destroyed at midnight UTC, Jan 1 2036". So even after we've switched to NTS, we'll still need to calculate UTC, so we'll still need leap-second announcements.

The schedule of leap seconds in the future isn't known, so such a timestamp isn't precisely defined yet anyway. Abolishing the practice fixes this.

> If they just stopped adding leap seconds to UTC at some point

That seems a fair point; and rather obvious - I'm embarrassed thatI don't have an answer.

Call it TAI https://en.wikipedia.org/wiki/International_Atomic_Time

TAI is the only sensible time scale, IMHO. It's monotonic, and it gives less than a shit about leap seconds.

Adjust for local display at the time you display it and only at the time you display it.

UTC would still have all the leapseconds from the past, it just wouldn't have any new ones added.

Leap-seconds are manually added, and don't follow a predictable pattern. They're different than leap-years in that respect.

We could all agree to stop adding leap-seconds, and nothing would change in 99%+ of all UTC time-handling code. We just wouldn't get any more leap seconds. The process of adding them is manual anyways, so we could stop it without breaking anything.

> so we could stop it without breaking anything

Well, until some sufficiently influential government or organization gets annoyed with the discrepancy with solar time and comes up with their own correction to the local clocks under their jurisdiction. Then at the bare minimum you need all the commonly used date/time libraries to be updatable with this information. Existing solutions like the tz database [0] might already technically support this, although I have to imagine that the logistics will be annoying at best.

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

The timezone database supports offsets into the seconds, although I've heard some applications will not support files with such offsets iCalendar feeds that they'd otherwise support, so it'd be a bit of a mess still. I can't imagine why a country would feel the need to have an offset measured in seconds, but there are a lot of countries, some of which really don't seem to value global consistency, so it wouldn't be terribly surprising. Combined with countries that insist on applying DST without advanced scheduling, that would be a lot of fun.

The limiting factor here is that the local jurisdiction would have the same computer problems that the rest of us do. They also would need a way to update their own clocks to reflect their own local time. So presumably it would be done within an existing framework, like defining a new time zone that is one second further from UTC.

Time zones are wide enough that the error from (missing) leap seconds are infinitesimal compared to the quantization to the time zone.

Leap seconds are a poor band-aid "solution" to a problem that nobody has.

Right, but I'm talking about solar time drift.

The point is that you get significantly more 'drift' by just moving east or west within a timezone. No government is going to care if the local time at solar noon at a certain location changes a few seconds over the years, given that the time at solar noon changes much more as you move throughout the timezone.

“Civil time” is an inherently political concept. There is no way that humans can coordinate globally on that concept without unwieldy treaty organizations.

It's also not something that even needs to be coordinated globally. This whole thing seems to be a giant confusion between the concepts of time and calendar (including timezones), and I am not sure why it is still ongoing even though the time coordination problem has been seemingly solved thanks to atomic clocks for some decades now ??

> "This record must be destroyed at midnight UTC, Jan 1 2036"

In all practical senses I don't think it would matter much if this record is destroyed a few seconds early or late in such a case...

Reply on news.ycombinator.com