Why does this NTP implementation accept a sudden change of 4 billion seconds? For example, the NTP implementation in Windows refuses to change the clock by more than 54,000 seconds.
Using that API avoids sudden jumps in time. The cost is that if a correction is required then the system time will be incorrect until the difference settles to zero. And you ideally need some PID control so that the system time settles quickly to match the "correct" external time.
For example you can spread a 1 second adjustment over an hour. Sometimes being up to one second out is less problem than a sudden jump of one second.
It is useful to have time monotonically increasing if you have software that depends on time differences (e.g. timestamps stored in logging systems).
Not sure if Microsoft gimped the API after XP - this note seems bad "Currently, Windows Vista and Windows 7 machines will lose any time adjustments set less than 16." Make it difficult to use API to steadily keep time synchronised closely.
Kinda. Clock slewing is the term used in NTP-land and is basically about making this kind of adjustment for small time differences (generally you want to run a control loop that adjusts the rate of the internal clock so that the time difference goes to zero, as opposed to simply changing the time, as one will result in a smooth time reading while the other will cause periodic jumps). Smearing is basically pretending that the leap second doesn't exist and using clock slewing to paper over the difference.
Linux systemd-timesyncd seems to have some limit, too. When our appliance-like systems get an invalid time from the hardware clock, they boot with a system clock of 2019 IIRC. systemd-timesyncd does not correct that depite me assuming that the ntp server works correctly.
Well, it happens rarely enough and we have workaround, so the bug report still sits in the queue behind more urgent problems. Haven't read the source yet, which is what you should do on Linux of course...
Using that API avoids sudden jumps in time. The cost is that if a correction is required then the system time will be incorrect until the difference settles to zero. And you ideally need some PID control so that the system time settles quickly to match the "correct" external time.
For example you can spread a 1 second adjustment over an hour. Sometimes being up to one second out is less problem than a sudden jump of one second.
It is useful to have time monotonically increasing if you have software that depends on time differences (e.g. timestamps stored in logging systems).
Not sure if Microsoft gimped the API after XP - this note seems bad "Currently, Windows Vista and Windows 7 machines will lose any time adjustments set less than 16." Make it difficult to use API to steadily keep time synchronised closely.