> On Aug 15, 2018, at 4:31 AM, Rob Stradling <[email protected]> wrote:
>
> I just started to prepare a PR for this, but...
>
> RFC6962 says:
> "timestamp" is the current NTP Time [RFC5905], measured since the
> epoch (January 1, 1970, 00:00), ignoring leap seconds, in
> milliseconds.
>
> 6962-bis currently says:
> "timestamp" is the current NTP Time [RFC5905], measured in
> milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring
> leap seconds.
>
> RFC5905 section 6 says:
> "In the date and timestamp formats, the prime epoch, or base date of
> era 0, is 0 h 1 January 1900 UTC, when all bits are zero."
>
> 1970 != 1900, and (IINM) NTP time does not ignore leap seconds.
>
> ISTM that what we're actually using is Unix time
> (https://en.wikipedia.org/wiki/Unix_time), and so we should say that we're
> using Unix time. It makes no sense to claim to be using NTP time if we're
> not actually doing that.
>
> Two possible ways forward:
>
> 1. Replace the "NTP time" references with "Unix time", and find a suitable
> reference (any ideas?) to point to.
>
> 2. Switch to actually using the 64-bit NTP timestamp format. This might
> confuse implementers that are already familiar with RFC6962 though.
>
> Any preferences? (I favour option 1).
Thank you for this. I think it’s important to define it to Unix time or
equivalent rather than NTP. At best, NTP is going to refer it to Unix time or
equivalent, and you’d have the problem of people debating what to do if they
use some other protocol than NTP.
I think that if you say, “64-bit, unsigned Unix time” it’s pretty well-defined.
You could even explain once that it’s the number of seconds since 1 January
1970 UTC and then it’s defined about as completely as possible.
Jon
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
