lfpinit() signed or unsigned?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> There should be no place that converts a l_fp to POSIX time and no need for a 
> pivot anywhere in the code. We are assuming that the environment will switch 
> to 64 bit time_t before 2038 and that the system initialization gets the time 
> close-enough before ntpd is started.  Close-enough is within 31 bits of 
> seconds.  At worst, we'll need a simple shell script.

One of us is confused.  It might be me - the cascading assumptions in this
code make my head hurt sometimes.

If ntpd never converts an incoming l_fp to POSIX time, how will we know
when and how much to skew the local clock?

To my understanding, 64-bit Unix time won't solve the problem the
pivot addresses. The problem will first arise after 2036 (in era 1) when the
seconds part of l_fp has first wrapped around.  At that  point, it will
be possible for a machine to receive l_fp values that look like they're
from the far future in era 1, because they shipped before the rollover
ending era 0.

To get around this, ntpd uses its local pivot to find the nearest point
(to the pivot) in absolute time that can correspond to the modular l_fp
value.  Then it computes the corresponding UTC time from that. Er, at
least I think that's what's going on.

I don't believe you can eliminate the pivot. Without that, I don't see
how you can resolve a timestamp that might be from a different era.

I do, however, agree with your goal of reducing the scope of l_fp usage
as much as possible.

> Gary noticed that the stats file stuff is using l_fp for time stamps.  I'll 
> fix that soon.

Yeah, please do.  That's just wrong.

> I think the calendar code will get significantly smaller when I delete the 
> stuff that is no longer used.

Looking forward to it.
-- 
		<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.