News for hackers. Stuff that matters.
Re:An Update on Leap Seconds by denton-scratch on Monday January 30, 2023 @07:45AM (#34578930)
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).

Re:An Update on Leap Seconds by someguydave on Monday January 30, 2023 @07:59AM (#34579022)
“Civil time” is an inherently political concept. There is no way that humans can coordinate globally on that concept without unwieldy treaty organizations.
Re:An Update on Leap Seconds by BlueTemplar on Monday January 30, 2023 @01:40PM (#34584390)
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 ??
Re:An Update on Leap Seconds by mavhc on Monday January 30, 2023 @08:03AM (#34579057)
Re:An Update on Leap Seconds by myself248 on Monday January 30, 2023 @02:21PM (#34585022)
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.

Re:An Update on Leap Seconds by mb7733 on Monday January 30, 2023 @08:51AM (#34579542)
> 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.

Re:An Update on Leap Seconds by denton-scratch on Monday January 30, 2023 @05:44PM (#34587647)
> 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.

Re:An Update on Leap Seconds by sebzim4500 on Monday January 30, 2023 @09:15AM (#34579818)
UTC would still have all the leapseconds from the past, it just wouldn't have any new ones added.
Re:An Update on Leap Seconds by dark-star on Monday January 30, 2023 @09:26AM (#34579935)
> "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...

Re:An Update on Leap Seconds by nrclark on Monday January 30, 2023 @12:51PM (#34583599)
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.

Re:An Update on Leap Seconds by tshaddox on Monday January 30, 2023 @01:34PM (#34584280)
> 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

Re:An Update on Leap Seconds by jedberg on Monday January 30, 2023 @02:12PM (#34584906)
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.
Re:An Update on Leap Seconds by toast0 on Monday January 30, 2023 @02:53PM (#34585461)
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.
Re:An Update on Leap Seconds by Nullabillity on Monday January 30, 2023 @03:14PM (#34585719)
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.

Re:An Update on Leap Seconds by tshaddox on Monday January 30, 2023 @03:57PM (#34586267)
Right, but I'm talking about solar time drift.
Re:An Update on Leap Seconds by mb7733 on Tuesday January 31, 2023 @06:38PM (#34603992)
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.