3 ms·

I'm not very familiar with ntpd, but this article doesn't cover what would happen if the half hour polling just happens to poll right during the leap second. If

by Buge 11y ago

I'm not very familiar with ntpd, but this article doesn't cover what would happen if the half hour polling just happens to poll right during the leap second. If the code receives "59 minutes and 60 seconds" but doesn't expect that to be possible, I could imagine that being a problem.

ams6110 11y ago
I don't think it would see this. It would see "59 minutes and 59 seconds" and either see a one-second discrepancy with the local system clock on that poll, or on the next one.
- jjoonathan 11y ago
  UTC inserts the leap second by extending the last minute before midnight by one second and does indeed specify that this ought to be shown as, for example, "59 minutes, 60 seconds, 123 milliseconds." NTP doesn't seem to use the human-readable format for its timestamps though. My 30 second skim says it uses a variation on epoch time that extends from Jan 1 1900 rather than Jan 1 1970. UNIX epoch time inserts the leap second by waiting until 1 second after midnight and then jumping the counter back 1 second (which corresponds to a long 0th second rather than a long 59th second, but whatever, in spirit you are right) [1]. I see two potential sources for error: a 1s correction/drift proving to be "too much" for synchronization in a system that typically sees corrections or drifts far smaller, or 2. a well-meaning fool writes assert(s<=59) in some code that touches a correctly-handled UTC stamp during the leap-second :-) [1] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
  - ams6110 11y ago
    I read yesterday that the leap second was handled by repeating the last second of the day. So you would see 59 seconds for two seconds but never 60 seconds. I guess different systems and time standards may handle it differently.
    - jjoonathan 11y ago
      I'm sure that's how some systems implement it and it's close enough to the truth that I'm sure it will frequently be reported that way in the news. But I'm also quite sure that the actual standards are as I said they were. See the wiki link for a detailed timeline.

by Buge 11y ago

ams6110 11y ago

I don't think it would see this. It would see "59 minutes and 59 seconds" and either see a one-second discrepancy with the local system clock on that poll, or on the next one.

jjoonathan 11y ago
UTC inserts the leap second by extending the last minute before midnight by one second and does indeed specify that this ought to be shown as, for example, "59 minutes, 60 seconds, 123 milliseconds." NTP doesn't seem to use the human-readable format for its timestamps though. My 30 second skim says it uses a variation on epoch time that extends from Jan 1 1900 rather than Jan 1 1970. UNIX epoch time inserts the leap second by waiting until 1 second after midnight and then jumping the counter back 1 second (which corresponds to a long 0th second rather than a long 59th second, but whatever, in spirit you are right) [1]. I see two potential sources for error: a 1s correction/drift proving to be "too much" for synchronization in a system that typically sees corrections or drifts far smaller, or 2. a well-meaning fool writes assert(s<=59) in some code that touches a correctly-handled UTC stamp during the leap-second :-) [1] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
- ams6110 11y ago
  I read yesterday that the leap second was handled by repeating the last second of the day. So you would see 59 seconds for two seconds but never 60 seconds. I guess different systems and time standards may handle it differently.
  - jjoonathan 11y ago
    I'm sure that's how some systems implement it and it's close enough to the truth that I'm sure it will frequently be reported that way in the news. But I'm also quite sure that the actual standards are as I said they were. See the wiki link for a detailed timeline.