Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Richard Gibson <[e-mail]>]

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.