Hacker News Reader

Comment by billpg | Hacker News Reader

Pick Two.

    A. A day is divided into a fixed number of smaller units.
    B. Each smaller time unit is of a fixed physical duration.
    C. The day cycle corresponds to the cycle of the solar day on Earth.

TAI picks A and B, allowing the solar cycle to drift from the time.

UTC picks B and C, adding leap seconds to keep track with Earth's solar day cycle.

UT1 picks A and C, redefining the "second" to the changing rate of earth's solar day cycle.

View on HN

Another way to think about it is that UTC is a combination of UT1 and TAI. It’s kept within 1 second of UT1 and is always a fixed integer offset from TAI.

TAI is an absolute time based on atomic vibrations. UT1 is a relative time based on astrometric systems.

It's not a fixed offset from TAI. The offset changes every time there's a leap second.

Also, there is no such thing as absolute time, because of relativity. We take pains to account for this by only measuring TAI on the Earth's geoid, but even so the uncertainty never reaches zero. Two "stationary" atomic clocks on the geoid are expected to drift by about a second every billion years or so. Sure, that's pretty good, but definitely no "absolute".

When you really think about it, the cesium atom and the earth's day/night cycle are both equally valid clocks. But the cesium atom measures time more similarly to the way we perceive time on a small scale. But, of course, our lives are scheduled based on the day/night cycle. So they both matter. UTC is the way we reconcile the two.

Ya, and Unix time decided they could fool people into thinking they had all 3, and as a result, every couple of years, time "jumps backward" by one second. It's hands down the worst option to use as the basis for a computing system that needs accurate timestamps, and it's made software developers really resent leap seconds.

Now the BIPM decided to "get rid" of leap seconds in UTC a couple years ago. I hope they come to their senses before 2035 when the change takes effect. Here's what will happen:

Rather than inserting a leap second every 1-2 years to keep UTC in sync with solar time, they plan to defer the problem to once every 100 or so years, and just insert like 50 leap seconds all at once. Think about that for a second. If leap seconds are so bad, how in the hell is the world going to deal with 50 of them at once after a century of oblivious complacency? They won't. They'll just say "Look, it's not worth it to have leap seconds in UTC anymore". Then, UTC will forever be just a constant offset away from TAI.

But we already have TAI. Why not just use TAI as your "source of truth", and let UTC be UTC? We'll have to introduce a new system to take the place of UTC and be in-sync with solar time; like how UTC used to be.

If we wait until UTC and UT1 differ by one hour, dealing with the adjustment will be no more difficult than dealing with time zones.

I thought that was the plan when they decided to give up on leap seconds.

I don't get the insistence on keeping nominal seconds-alignment (or even minutes-alignment) between the clock and the sun's position; we already don't experience it in practice.

Timezone regions are fudged all over the world[1] for political and practical reasons, but even if they weren't, people living near one timezone edge don't experience the "sun noon" at the same time as people living near the other edge, even though they share the same clock time.

[1] just look at the map here: https://en.wikipedia.org/wiki/Time_zone

It has nothing to do with time zones. People can deal with weird time keeping practices, but distributed software systems can become completely borked. It's happened before in all sorts of different ways. Transaction order can get messed up. Event queues can drop or duplicate events. Obviously, it's a big problem, otherwise people wouldn't be so intent on getting rid of them. And having a leap hour instead of a leap second would be a whole order of magnitude worse, especially if it occurs after hundreds or thousands of years of people writing software that's oblivious to the phenomenon.

But completely getting rid of leap seconds for UTC is misguided. We already have TAI, which is literally just UTC without leap seconds. If leap seconds are messing with your system, just use TAI. Don't make UTC a slightly worse version of TAI.

I feel like I'm taking crazy pills.

> I feel like I'm taking crazy pills.

Civil society around the world has decided on UTC as the basis for time. What’s easier, convincing everyone to switch to TAI or changing the definition of UTC? I would guess it’s the latter.

> It has nothing to do with time zones. [...] And having a leap hour instead of a leap second would be a whole order of magnitude worse [...]

The idea is exactly to not have a leap hour, UTC is kept completely untouched. Everyone changes their timezone instead, exactly like we already do with daylight savings, except this would happen only once every few thousands of years instead of twice a year.

Well the current plan according to the BIPM is to keep adjusting UTC, but with bigger and less frequent adjustments. I'm predicting they'll change course in a hundred years, as you say, and just give up on leap seconds/minutes/hours altogether. So yes, I agree that this is the most likely scenario.

But again, we already have a time system that does not have leap seconds/minutes/hours. TAI and UTC would become effectively redundant. I don't understand why we need another version of TAI.

I agree with everything you said, I just don't see why we need both UTC and TAI. That is, I don't understand why we insist on keeping UTC synchronized with Earth's orientation.

On the one hand (like you said before), UTC is what we use for stuff like ordering transactions, which has absolutely nothing to do with the position of the Sun in the Sky.

And on the other hand, we already use timezones to reconcile the rough position of the Sun with our universal clock. Timezones only have resolution of 1 hour (or half in very few places), but looking at how fudged a lot them are, people don't really seem to care. I mean, look at Argentina, which fits almost perfectly in UTC-4 but chooses to use UTC-3 instead. China is even crazier, using a single time in its whole territory which could easily have 3 or 4 different timezones.

At it's core, UTC is about reconciling 2 different clocks; the Earth (basically represented by UT1) and the Cesium atom (represented by TAI). It's a useful basis for Civil time -- which is naturally political -- because everybody seems to intuitively agree that seconds should be defined by the Cesium standard but days should be aligned with the Earth's rotation. It's not guaranteed that all governments would pick the same if forced to pick only one of the two. That would make time zones even harder.

Sure, people in Western China may regularly see the sun at midnight, but that's not without controversy. People generally like the sun to be out when they're up.

So I think it makes sense to have both UTC and TAI. If the BIPM just turns UTC into TAI plus a constant offset, then I'd wager they would eventually introduce another system to take the place of the former UTC, with leap seconds, so some people can have that system that reconciles the two clocks if they want it. It's hard to predict the future. But the reasoning in the GCPM resolution [1] seems inherently flawed to me. "recalling that the CGPM at its 26th meeting (2018) ... stated that UTC is the only recommended time scale for international reference" is the core of the problem. TAI should be the ultimate basis. UTC is based on TAI (with leap seconds), and civil time based on UTC.

[1]: https://www.bipm.org/en/cgpm-2022/resolution-4

> I feel like I'm taking crazy pills.

I always told our new-hires to avoid thinking too deeply about computer timekeeping if they value their sanity.

Time can only be measured by clocks (oscillatory systems). It's a slippery concept for which humans have a natural, flawed intuition. But if you understand your clock(s) really well, then timekeeping makes perfect sense. There's just a lot of clocks around. There's Unix time, UTC, TAI, smeared UTC, stop-the-clock UTC, UT1, and lots of others. Make sure you understand the clocks your system is using and how they relate to one another, and you can keep your sanity.

Glad to see that this is being understood now.

https://news.ycombinator.com/item?id=28047376

https://news.ycombinator.com/item?id=29926509

> A. A day is divided into a fixed number of smaller units.

> B. Each smaller time unit is of a fixed physical duration

This just gave me Timecube flashbacks

And I guess POSIX tries to pick all three, at least most of the time. It follows UTC mostly, except during leap seconds when it changes the duration of a POSIX-second to be 2 SI-seconds (positive leap second) or 0 SI-seconds (negative leap second).

POSIX time_t picks A and C.

99.999998% of time_t ticks from 1970 until now have been 1 second long. 27 have been 2 seconds long. Therefore B ("each smaller time unit is of a fixed physical duration") is the variant.

Actually, this sort-of describes "smeared UTC", which is used by some computer systems such as Google's NTP servers: https://developers.google.com/time/smear

POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.

I think you're talking about struct timespec, I'm talking about time_t.

I don't think "POSIX time" specifies behavior during leap-seconds for the functions that return timespecs (gettimeofday() [0] and clock_gettime(CLOCK_REALTIME) [1]), so any behaviour would be valid - including smearing or repeating nanoseconds?

[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...

Doesn't it only pick C? Negative leap seconds make POSIX time skip a second.

POSIX time_t still ticked, but the interval between the ticks was 0s, rather than 1s or 2s.

It preserves A (exactly 86400 ticks per calendar day) and C (remains in alignment with UTC) by abandoning B (each tick has a fixed duration)

One could also make ticks on such a day last 86400/86401 or 86400/86399 seconds, keeping the tick duration fixed but only for a given day (a relaxed version of B)

Just came here to say that I like your explanation: succinct and correct. I am stealing it for my blog post.

https://robotsinplainenglish.com/e/2022-11-20-stopwatch-time...

Reply on news.ycombinator.com