Work item list: l_fp_time and l_fp_offset

Gary E. Miller gem at rellim.com
Wed Apr 26 20:26:24 UTC 2017


Yo Achim!

On Wed, 26 Apr 2017 22:20:17 +0200
Achim Gratz via devel <devel at ntpsec.org> wrote:

> Gary E. Miller via devel writes:
> >> What exactly do you suggest to replace it with?  
> >
> > Timespec with time64_t.  
> 
> Is that POSIX yet?

Nope.  There is no generic standardized solution yet.  Until an
OS gives us a way to set time past 2038 nothing that NTP can do.

> > As Linux 64-bit uses now for native time.  Then
> > the timestamp arithmetic does not lose precision and the first
> > time64_t rollover is centuries from now.  
> 
> I'm not sure what you try to gain there, but you are certainly not be
> able to stuff that into registers or call stack and instead have
> pointers to a structure.

Well, that is what ntpd does now on 64 bit linux and glibc, so not a
change at all.  It just works.  I see no reason to try to fight Linux
or glibc.  Go with their flow.

>  Again, as long as you can reconcile the time
> at startup, there is absolutely no problem with any rollover during
> the operation of ntpd that results from the use of l_fp.

Yes, agreed.  The startup is the problem.  Once we have that
everything is good.

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/20170426/5fdc9108/attachment.bin>


More information about the devel mailing list