l_fp, time, calendar

[Hal Murray]

I just removed a pile of unused code from libntp/ntp_calendar.c

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.

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.)

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.

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.  ??

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.


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.

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.


-- 
These are my opinions.  I hate spam.