> If the resulting time that ntpd sees is more than a few milliseconds off, it'll step the clock, and that will clear out the future time.
It shouldn't do that, otherwise it's going to break in 2036.
(The "future time" it's going to clear off will set the time back to 1900 once we are past February 7, 2036)
Edit: I don't know if I didn't explain myself well enough. Because the protocol only has 32 bits of seconds it cannot tell apart September 27, 2017 and November 4, 2153. This means that ntpd absolutely must trust that it is in the correct 68-year span. But according to the author ntpd "clears out the future time" if it is more than a few milliseconds off. This violates the spec and is also inconsistent as it happily keeps up with the future date as long as it doesn't have to step the clock.
I often see this type of comment on many subject and I find it super weird in a way. I mean, if it took you less than a minute after reading it to spot the issue despite not being familiar with the details before, it's usually safe to assume whoever made the specs and spent days on it also did.
I didn't say you did? You pointed an obvious error. I'm saying, yes, I'm pretty sure we can assume it's been handled already given how easy it is to spot (and the other comment to your message seems to imply it is indeed)
You made it sound like? Of course it is handled by the spec, the issue here is in ntpd not following the spec (assuming what the author says is true, I haven't checked).
Or actually there is this little tidbit from RFC 5905:
> Eras cannot be produced by NTP
directly, nor is there need to do so. When necessary, they can be
derived from external means, such as the filesystem or dedicated
hardware.
So it could be that ntpd looks at some file or the rtc to determine the era rather than assuming the current system time is in the correct era, and it would be allowed by the spec. But it's quite inconsistent if it only does it if the system time is more than a few milliseconds off (presumably beyond the limit of when it corrects the time by time stretching). I'm going to go with it just being a bug in ntpd.
Sorry if you understood me that way. I was reflecting on some things that I see often on hn, eg a common case is when Google annonce a change in crawling and people go "but it can be gamed by...".
Your message merely reminded me of that and so I put my message here as I saw similarity. Having not read the ntpd spec in question I can't answer you.
It shouldn't do that, otherwise it's going to break in 2036.
(The "future time" it's going to clear off will set the time back to 1900 once we are past February 7, 2036)
Edit: I don't know if I didn't explain myself well enough. Because the protocol only has 32 bits of seconds it cannot tell apart September 27, 2017 and November 4, 2153. This means that ntpd absolutely must trust that it is in the correct 68-year span. But according to the author ntpd "clears out the future time" if it is more than a few milliseconds off. This violates the spec and is also inconsistent as it happily keeps up with the future date as long as it doesn't have to step the clock.