6 ms·

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 monotoni

by mritun 4y ago

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-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti... edit: link

vesinisa 4y ago
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.
- ncmncm 4y ago
  Not all the others. Just those who have not made the similarly wise choice.
kosherhurricane 4y ago
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).
- joerichey 4y ago
  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 https://en.wikipedia.org/wiki/Precision_Time_Protocol
  - luhn 4y ago
    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?
    - mongol 4y ago
      Seems like a simple and accurate way to handle it.
    - kosherhurricane 4y ago
      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.
      - Unklejoe 4y ago
        > GPS runs TAI GPS time is actually 19 seconds behind TAI at all times.
    - SkeuomorphicBee 4y ago
kosherhurricane 4y ago
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.
NovemberWhiskey 4y ago
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...
ncmncm 4y ago
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.

by mritun 4y ago

vesinisa 4y ago

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.

ncmncm 4y ago
Not all the others. Just those who have not made the similarly wise choice.

kosherhurricane 4y ago

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

joerichey 4y ago
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 https://en.wikipedia.org/wiki/Precision_Time_Protocol
- luhn 4y ago
  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?
  - mongol 4y ago
    Seems like a simple and accurate way to handle it.
  - kosherhurricane 4y ago
    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.
    - Unklejoe 4y ago
      > GPS runs TAI GPS time is actually 19 seconds behind TAI at all times.
  - SkeuomorphicBee 4y ago

kosherhurricane 4y ago

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.

NovemberWhiskey 4y ago

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

ncmncm 4y ago

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.