Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

Edit: This comment was not accurate

Unix/Posix time doesn’t include leap seconds (it’s 86400 seconds per day, always, per definition [0]), whereas UTC, taken as a count of actual seconds, does include leap seconds. So you are right that converting between them requires additional data. However, few applications care about converting between Unix time and that notion of UTC, but instead care about converting between Unix time and calendar dates and times of day and time zones, which is easier with Unix time than with a UTC seconds count. So I think you’re mixing things up here.

[0] https://en.wikipedia.org/wiki/Unix_time#Definition

In the link you provide it says this about Unix time:

    In Unix time, every day contains exactly 86400 seconds but leap seconds are accounted for.

It then provides an example for when the Unix time went from 915148800 to 915148800 after 1 atomic second on 1998-12-31T23:59:60.00

So it's incorrect to say that Unix time does not include leap seconds.

It would be more accurate to say that Unix time "accounts for" leap seconds by not accounting for them at all, but rather switching into temporal displacement ambiguous repeat timestamp la la land for an entire second before returning to an unambiguous encoding of UTC.

Leap seconds are not counted in Unix time. Otherwise days with leap seconds would be counted as having 86401 seconds instead of 86400 seconds. This is not the case. In the example you cite, the Unix time resets to 915148800 after the leap second (1999-01-01T00:00:00), so the leap second isn't counted. Unix time differs from the true number of seconds since the epoch by the number of leap seconds (plus the UTC-TAI time difference between 1970 and 1972, before leap seconds were introduced).

The leap second is being abandoned:

https://www.nature.com/articles/d41586-022-03783-5

Presumably this means no more leap seconds to be added but we'll be stuck with the ones we've got?

Most likely. They could add leap minutes, hours, or days instead. But they'll probably set UTC as a constant offset from TAI, and let the few uses that care about accurate solar time use UT1.

UTC can never be set as a constant offset from TAI, it will eventually cease to be useful and that can never happen.

TAI is very useful. The thing people seem really anxious about is that it isn't directly tied to the Earth's rotation. But, like, so what?

If you want something tied to Earth's rotation, UT1 is the way to go. If you don't care, TAI is good. UTC is in a weird compromise position, where it (traditionally) tried to be within 1s of UT1 but otherwise tick at the same rate as TAI. That compromise turned out not to be what anyone needs, so future uses will probably pick between UT1 and TAI/GPS/Unix/some other fixed offset from TAI.

Reply on news.ycombinator.com