5 ms·

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 need

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).

mavhc 4y ago
Call it TAI https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time
- myself248 4y ago
  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.
someguydave 4y ago
“Civil time” is an inherently political concept. There is no way that humans can coordinate globally on that concept without unwieldy treaty organizations.
- BlueTemplar 4y ago
  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 ??
mb7733 4y ago
> 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.
- denton-scratch 4y ago
  > 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.
sebzim4500 4y ago
UTC would still have all the leapseconds from the past, it just wouldn't have any new ones added.
dark-star 4y ago
> "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...
nrclark 4y ago
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.
- tshaddox 4y ago
  > 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 https://en.wikipedia.org/wiki/Tz_database
  - jedberg 4y ago
    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.
  - toast0 4y ago
    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.
  - Nullabillity 4y ago

mavhc 4y ago

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

myself248 4y ago
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.

someguydave 4y ago

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

BlueTemplar 4y ago
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 ??

mb7733 4y ago

> 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.

denton-scratch 4y ago
> 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.

sebzim4500 4y ago

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

dark-star 4y ago

> "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...

nrclark 4y ago

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.

tshaddox 4y ago
> 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 https://en.wikipedia.org/wiki/Tz_database
- jedberg 4y ago
  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.
- toast0 4y ago
  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.
- Nullabillity 4y ago