12 ms·

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 us

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
    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.
- fanf2 4y ago
  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.
  - fanf2 4y ago
    “hateful”? oops! i meant “careful”
  - joerichey 4y ago
    Whoops! You're right, instead of "successor" I should have just said "newer".
cesarb 4y ago
> 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.html 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.

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
  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.
fanf2 4y ago
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.
- fanf2 4y ago
  “hateful”? oops! i meant “careful”
- joerichey 4y ago
  Whoops! You're right, instead of "successor" I should have just said "newer".

cesarb 4y ago

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