Yo Hal! On Fri, 10 Mar 2017 12:40:11 -0800 Hal Murray <hmur...@megapathdsl.net> wrote:
> g...@rellim.com said:
> >> Be careful with making negative values. The case I'm worried about
> >> is dropping the carry out of the low half.
> > The code has a normalize_tspec() ir prolly needs a
> > normalize_lp().
>
> There is nothing to normalize in a l_fp All bit patterns are valid.
Sort of. The header notes imply the integral and fractional part may be
signed or unsigned. Separately. I have not confirmed if the code use
that.
> > Because a RasPi has no RTC. When it starts up it is always 1970
> > again. When 2036 comes, how will the RasPi know it is 2036 and not
> > 1970?
>
> I think the build date of the code will be a good start.
Which breaks regression tests. We tried that on gpsd and the
results were, to be kind, loud.
Actually, there may be a better way. NTP defines an Epoch on the
wire. I do not know when it is sent. We are currently in NTP Epoch 0.
In 2036 it goes to NTP Epoch 1. If we can grab that field off
the wire we are good.
Semms I believed someone that misread the RFC. NTP Time is based on
1Jan1990, but when using the Epoch it can uniquely define any time
backwards or forward.
I just updated the comment in includes/ntp_fp.h.
> >> ctl_putfs is only used to printout leap second dates.
> >Looks to me like it is creating an NTP mode 6 message in wire
> >format.
>
> The text on the wire is a date string:
> snprintf(cp, sizeof(buffer) - (cp - buffer),
> "%04d%02d%02d%02d%02d", tm->tm_year + 1900,
> tm->tm_mon + 1, tm->tm_mday, tm->tm_hour,
> tm->tm_min);
Yeah, I went back to the file after getting it wrong. I noticed that
code was obfuscated and tweaked it. The conversion is from NTP Epoch to
POSIX Epoch. A good place to use the existing conversion macro.
>
> The values getting printed are coming from the leap-second file.
> # The NTP timestamps are in units of seconds since the NTP
> epoch, # which is 1 January 1900, 00:00:00.
> They are strings, so we don't have to worry about overflow. We can
> convert to POSIX time_t when they are read in with a simple sub.
Good catch, another obfuscating use of l_fp!
> [My offer to try to fix that area]
Sounds like you have a way better handle than I do. I'm off to
find other obfuscation.
If is is not obvious, many thanks for helping in this thicket! I can
get lost in the twisty maze of passages, all seemingly alike...
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@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
pgpfTNmUbM6Qw.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
