Hacker News Reader

Comment by lmm | Hacker News Reader

Storing UTC (or rather TAI) is a silver bullet for "system" times - things that need to happen on a regular schedule, where we care how much time has passed between one instant and another, or things where we want to record at what instant something happened, and correlate system events with each other.

Indeed it doesn't solve the problem of handling user-inputted "human" times correctly. But that is a much rarer case than needing to handle "system" times. Many - probably most - applications never need to handle a "human" time at all.

View on HN

I prefer TIA over UTC and wish it was widely used.

Leap seconds mean the same UTC time can happen twice if we fall back a second, or a UTC time may never happen when we skip ahead a second. Leap seconds also mean that epoch milliseconds derived from UTC do not represent milliseconds between the timestamp and Jan 1 1970 unless the conversion is aware of all leap seconds. Leap seconds are prescribed every six months with six month notice. There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.

I'm pretty happy with ISO-8601, but dates after the year 10,000 will not sort lexicographical. A 64 bit signed int storing milliseconds since Jan 1 1970 covers 29225733 B.C to 29229672 A.D

>There are many time keeping devices that are not updated as often as UTC leap seconds are introduced.

Isn't this an argument against using TAI in certain applications though? i.e. if you're designing a system which relies on non-leapsecond-updated devices to be in sync with devices that are capable of being updated, you should always design as such to accommodate the former rather than the latter?

No? It's an argument for using TAI,because devices that use TAI do not need leap second updates - a clock running TAI that was started in 1970 and never updated will show the same time as a clock running TAI that's started today (or one that was started in 1970 and updated continually), whereas a clock running UTC that wasn't updated will show a different time from one that was updated.

For most timekeeping devices, the inherent drift and skew noise floor is above the leap seconds error.

Honestly, I think that leap seconds were simply a mistake. We could have phase-locked UTC to UT1R via frequency changes instead of via phase changes and much of that hassle would have been avoided.

UT1R is a time of day measurement that is based on making astronomical observations to establish the Earth's angular velocity and phase very precisely with respect to TAI. Leap seconds are created from time to time to keep the offset between UTC and UT1R to less than a half-second.

In effect, UTC is slaved to UT1R via a PLL that is only capable of making phase jumps. Instead, we could have slaved UTC to UT1R via a PLL that only ever made frequency changes. There would be no phase jumps (leap seconds), just very subtle adjustments in clock frequency. Those adjustments are fine enough that the majority of users don't care. The remaining users were already using TAI anyway.

Leap seconds are nothing to worry about when you're dealing with calendar times and dates in business. They are just a real-time clock adjustment which disappears from the calendar, which uses calendar seconds.

We can't phase lock real seconds to calendar seconds, because calendar seconds are a moving target. As the Earth's rotation slows, calendar seconds get longer. Seconds that get longer are not acceptable in science.

> We can't phase lock real seconds to calendar seconds, because calendar seconds are a moving target. As the Earth's rotation slows, calendar seconds get longer. Seconds that get longer are not acceptable in science.

Sure you can, and yes they are. There can be a difference between calendar seconds and atomic seconds. For most applications the difference is irrelevant. People doing science can explicitly account for the differences. And since most time-keeping in science is much more inaccurate than the difference between the speeds of TAI and UT1R, those folks won't care.

Most of the applications that do require very precise timekeeping actually only care about having a very consistent timebase, they don't necessarily care as much about the speed of time. So even if we steered GPS time by enough to use it as a broadcast source of UT1R, the majority of users who use GNSS to synchronize their measurements also don't care.

The remaining handful that do care are going to be purchasing atomic clocks anyway, and there are dedicated mechanisms available to synchronize those to TAI.

Reply on news.ycombinator.com