e...@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 it. 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 time. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
