Hacker News Reader

Comment by mritun | Hacker News Reader

A million problems started when system clocks were changed to follow UTC (as opposed to local time) and then UTC was conflated with Unix time - a fixed monotonic reference, which UTC is not!

Though the ship has sailed, I think it could have been much better if computers were set to follow TAI Time (atomic clock time - unaffected by leap seconds) time than the UTC. UTC is as variable as localtime and should have been treated as such.

If fb wants to - they can (and should) use TAI time for system reference.

TAI : https://www.nist.gov/pml/time-and-frequency-division/nist-ti... edit: link

View on HN

I totally support this. In fact, I would say all computer systems should just use TAI, and display UTC to the user.

Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).

This is actually what the Precision Time Protocol (PTP) does. It's the successor to NTP, so it improves on some of NTP's mistakes. The protocol uses TAI, but also sends the TAI-UTC offset so the computer can display times in UTC.

https://en.wikipedia.org/wiki/Precision_Time_Protocol

Why does the time protocol need to send the UTC offset, rather than have the offset be part of system data files, like with timezones? Wouldn't you need the data anyways to translate historical timestamps to UTC?

Seems like a simple and accurate way to handle it.

I think this is the argument NTP makes for not including the offset. TAI can be just another "timezone", so that TZDATA should be to used it to derive it.

But that's backwards. A Stratum 1 NTP usually gets its data from GPS, which HAS the offset (GPS runs TAI). But it only outputs UTC, but not the offset, making other programs compute it from TZDATA. Why is NTP making user programs harder to get the data that IT ALREADY HAS? Because philosophically, NTP is married to UTC (even though NTP is mostly for computers!)

And providing this offset would basically get rid of a large body of people (like the TFA) who wants to CHANGE the definition of UTC, which is a more drastic proposal.

> GPS runs TAI

GPS time is actually 19 seconds behind TAI at all times.

Those are two different problems that require two different solutions:

1. Displaying current time: for that ideally you need the offset directly from the time server because the system timezone data can be out of date in regards to current time.

2. Displaying historical timestamps: for that you use the system timezone file.

PTP and NTP have completely different scopes: PTP requires end-to-end layer 2 support and hateful choice of hardware, so it can only work within a single network; NTP on the other hand was always designed to work across the internet between different organizations, where the network doesn’t help with timekeeping and the organizations don’t work closely with each other.

Whoops! You're right, instead of "successor" I should have just said "newer".

“hateful”? oops! i meant “careful”

> Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).

There's a draft of the next version of the NTP protocol (NTPv5) at https://www.ietf.org/archive/id/draft-mlichvar-ntp-ntpv5-04.... which not only has the option of working in TAI, but also has explicit support for "leap second smearing". It also has a field to explicitly provide the TAI offset.

This sounds like a sensible solution. If Facebook wants to start using non-UTC time coordination, like TAI, they by all means should try it. They only need to publish their own NTP servers I guess, but that shouldn't be a big problem for an organization of their size.

As far as I can tell, TAI will always be offset from UTC by an integer amount of full seconds, and I guess time coordination between large independent systems is mostly useful just when comparing log timestamps (I would guess almost all sensible software uses already account for much larger clock drifts than the current leap second count of 37, right?)

After adopting TAI, Facebook engineers just need to remember that their log timestamps are offset by N seconds from all the others.

Not all the others. Just those who have not made the similarly wise choice.

Unix time is definitely not a fixed monotonic reference; in fact it's defined explicitly to exclude leap seconds in the count since the epoch...

The ship has not, in fact, sailed: UTC could abandon leap seconds any time. They just need to announce there won't be any more, for the foreseeable future. Along about 2100 they might announce plans for a correction in 2125 or so.

It seems the problem of adopting TAI for computers is because the NTP protocol does not provide the offset. We should add TAI-UTC offset to the NTP protocol.

Reply on news.ycombinator.com