Big picture...

[Gary E. Miller]

Yo Hal!

On Mon, 17 Apr 2017 20:26:52 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> I think we are reasonably close.)

+1

> The packet code uses l_fp.  The OS interfaces use timespec and
> time_t.

Yes, pertty much as it is now.

> The code in the middle works in time offsets using seconds
> in doubles and some time in time_t.

Currently, sort of, yes.

But, I see no point not to do the offsets as timespec's too.  Otherwise
big time corrections need multiple jumps due to loss of precision in the
doubles for large 'gate' times.  And the time sve in doubles is lost in
the converting back and forth.

> t seems like a good goal.  I
> think we are close.  That was the direction I was going when I got
> rid of a lot of time64_t a while ago and when I cleaned up the
> leap-second code.

Yes, we had good momentum, but then I got stuck in the warning, which
flushed out a lot of little junk and will be hard to do after 1.0.

Most of the isolated pointless usage of l_fp's can be converted to
tiemspec(64) with no problems.  The timespec(32) people are hosed no
matter what we do in 2038.


> I'd like to get rid of ntp_calendar.  Nothing urgent, it just seems
> like we should be able to use POSIX date/time calls instead.  I made
> some progress in the recent leap-second cleanup.

May not be totally possible, but close.  If all but the NTP external
interface is timespec(64) then no need to carry a lot of oddball time
arithmetic.

> One rough edge is that there is no UTC version of mktime.

Yeah, a PITA, but ugly solutions abound..

> For the leap-second code, I used 28 days rather than 1 month.  I
> could do that calculation with simple arithmetic.

Yet another can of worms...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170417/e2536bd7/attachment.bin>