Hal Murray <hmur...@megapathdsl.net>: > > g...@rellim.com said: > > Yeah, I see that now. But as you pointed out, NTP time is already modulo, > > so it only fails immediately after the rollover. > > > But that rollover is gonna be rough... > > I think it should be clean if/after we get the code right. > > Assume we have 64 bit Unix/POSIX time_t. The only interesting case is > converting NTP time to Unix time. That should work the same way that GPS > week rollover does. You need to figure out via some out-of-band source what > the time is within 68 years. The build time of of ntpd is one source. The > file system is another, but that can go crazy if you somehow get the time set > way in the future. The operator is another option. Maybe ntpv5 will provide > a way. Maybe one of the sec options. > > Does the current code have the right variable? Have you found it? Is there > more than one place that does NTP to Unix conversion?
What you're looking for is called the "pivot point", snd it's implemented in libntp/systime.c. There used to be sporadic NTP-to-Unix conversions all through the code. I moved as many of them as I could find to use lfp_stamp_to_tspec(), but I'm not sure I got them all. A good way to check would be to grep for JAN1970 and look at the code near those hits. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel