l_fp, time, calendar

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> I just removed a pile of unused code from libntp/ntp_calendar.c

*applause*

> In the process of poking around....
> 
> Quick summary:  I think the old code tried to use l_fp format times all over 
> the place.  That may have made sense in the pre POSIX days, but I think we 
> should switch to time_t and timespec everywhere except in the packet.

I concur.  Good thinking.

> There is a bunch of l_fp in the refclocks.  That's coming from the recvbuf 
> where l_fp is the right format for the arrival time which goes into the 
> return packet in server mode or into the calculations in client mode.  In the 
> long run, I think that should change to a timespec.  In the short term, we 
> can add a duplicate timespec version to avoid converting back and forth while 
> we clean things up.  (The time starts out as a timespec.  Now, it gets 
> converted to l_fp before it is stored in the recvbuf.  I think it should get 
> stored as a timespec and converted in the two places where it needs l_fp 
> format.)

I again concur.

> The NMEA driver has a bunch of calendar code.  One chunk is converting 2 
> digit years to 4 digit and worrying about pre 2000.  That seems simple to 
> simplify.

Agreed.

> I think another chunk is trying to dance around 1024 week roll over.  That 
> comes from PGRMF sentences which I think are Garmin propriety.  But there is 
> a normal DDMMYY in there, so I don't see why we need the GPS stuff.  ??

Because it's not YYYY.  There is much evil in the way two-digit year
wraparounds interact with GPS week-counter rollovers.  I used to know
all the painful details - I had to in order to make the NMEA driver in
GPSD do the right thing - but I've half-forgotten them since.  I tried
to comment those parts of the NMEA driver with care; you might find reading
it enlightening.

> Does gpsd handle broken units that are off by 1024 weeks?  If so, I vote to 
> dump all that code and let gpsd handle any broken units.

Answer: That turns out to be a wicked problem.  In the end all you can
do is assume that the host-system clock is accurate *to within the
current GPS era* at gpsd startup time.  Yes, this means potential trouble
on embedded deployments that reboot close to a rollover and don't have
a persistent RTC, but there's no help for that.

But I agree - we should drop the kluges that aren't straight NMEA from the
NTPsec driver and let GPSD handle the weird cases.  That's what it's
specialized for.

> There is some pretty date stuff using l_fp called from python.  I vote we 
> write some python code that converts l_fp into a python time.  Eventually, it 
> will have to pivot but we can punt for a few years.

Not seeing a point in this unless it removes the last blocker to getting
rid of prettydate() entirely.

> We should probably invent something like a timespec so we keep all the low 
> order bits.  If I'm counting right, there are 53 bits of fraction in a 
> double.  With 32 for seconds, that leaves only 21 for fraction.  That's 1/2 
> microsecond.

I'm wary of this.  I'd like to hear more explanation of why you think
we need 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.