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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
