On timekeeping:
On 11/22/18 07:01, Sara Dickinson wrote:
Section 7.5.1
Does "earliest-time" include leap seconds?
Thanks for noticing this…after digging into it…
The description specifies the number of seconds to be the
number of seconds since the POSIX epoch ("time_t"). POSIX requires that
leap seconds be omitted from reported time, and all days are defined as
having 86,400 seconds. This means that a POSIX timestamp can be
ambiguous and refer to either of the last 2 seconds of a day containing
a leap second (who knew time could stand still in POSIX world - aargh?!)
However, libpcap (for example) can only provide POSIX timestamps for
packets as far as we can see…
Do you think we should just document this as a limitation or do you have
another option in mind?
I am currently going through a similar exercise in another context, and
the best current text there explicitly characterizes the non-obvious
day-based accounting of POSIX time. In this context, it would look
something like
A time value that is a multiple of 86,400 (i.e., is equal to 86,400
× /d/ for some integer /d/) represents the instant at the start of
the UTC day that follows the 1970-01-01T00:00Z epoch by /d/ whole
UTC days. Every other finite time value /t/ is defined relative to
the greatest preceding time value /s/ that is such a multiple, and
represents the instant that occurs within the same UTC day as /s/
but follows it by /t/ − /s/ seconds.
Time values do not account for UTC leap seconds—there are no time
values representing instants within positive leap seconds, but there
are time values representing instants removed from the UTC timeline
by negative leap seconds. However, the definition of time values
nonetheless yields piecewise alignment with UTC, discontinuities
only at leap second boundaries, and zero difference outside of leap
seconds.
However, there may be C-DNS purposes that cannot tolerate such
discontinuities, and they would presumably want to use a continuous
monotonic timescale with a fixed offset from TAI (as is the case for
e.g. GPS time). It would be nice to have a field in StorageParameters
defining the time scale and therefore proper interpretation of
Timestamps, defaulting to UTC-approximating POSIX but also accommodating
unadjusted seconds counting.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
