Time to slow down and be more careful
hmurray at megapathdsl.net
Mon Apr 17 21:46:07 UTC 2017
esr at thyrsus.com said:
> This morning, while investigating a recent code change that smelled bad to
> me, I discovered that an error cascade of small, wrong changes starting some
> weeks ago had destroyed the mechanism that would allow instances of ntpd to
> interoperate across the epoch 1 boundary in 2036.
Could you please say more. If I screwed up, I'd like to learn something from
Looking back, I should have written something about how that stuff works.
It's in several messages but never made it to a file that got committed.
I think the old code converted l_fp to full time. That needs a pivot.
I changed things so that there is never a conversion from l_fp to full time.
There is a subtract done on the l_fp side. The clock offset in l_fp is
converted to an offset in seconds. I think it's a double. That eventually
turns into a clock adjustment. There is no explicit pivot. There is an
implicit pivot of the current time.
That turns into a requirement for the time to be reasonably close before ntpd
is started. Reasonably close is within 68 years.
That will screw up in 2038 on systems like the Raspberry Pi that don't have a
battery backed RTC. I see two ways to fix that. One would be to put a pivot
like time stamp into ntpd and early in the startup sequence, bump the clock
if the current time is earlier than the pivot. The other would be to run
some other program before starting ntpd. That program could use a compiled
in time stamp or look in the file system or ...
This area is also tangled up with time_t being 32 or 64 bits. We decided to
use time_t as much as possible, expecting the environments to fix that in
These are my opinions. I hate spam.
More information about the devel