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
