[pcap-ng-format] Issue #24: Need to specify the IDB if_tzone option format

[Stephen Donnelly]

On Wed, Aug 26, 2015 at 9:39 AM, Guy Harris <guy at alum.mit.edu> wrote:

>
> Positive leap seconds have valid UTC values - they just happen to have
> ":60" or ":61" rather than ":00" throught ":59" at the end of the label.
>
> What those leap seconds lack is:
>
>         a valid *POSIX time* value - the way POSIX time is defined makes
> that impossible;
>
>         from at least one MSDN document, a valid Windows FILETIME value,
> as those also treat leap seconds the way POSIX time stamps do.
>
> Time stamps that are specified as a count of *all* seconds, including leap
> seconds, and fractions of a second since some specified epoch, are ideal
> for:
>
>         1) attaching UTC labels to packet arrival times;
>         2) calculating the difference between packet arrival times.
>
> They aren't ideal for attaching "POSIX time" or "Windows time" labels to
> packets, as you need to compensate for those labels not matching UTC.
> They're also not ideal for packet time-stamping code on OSes where the
> clock keeps "let's ignore leap seconds" time rather than UTC.


You are correct of course, however the issue remains that the POSIX/Windows
time encoding is ambiguous at several points. Does the pcapng explicitly
specify POSIX/Windows time encoding, or does the reference to UTC imply
that the time stamps are monotonic?

A monotonic count of seconds since an epoch is in practice what both TAI
and GPS provide (there is a fixed offset between them due to different
epochs). TAI is the default time base for PTP and IRIG-B clocks, so is
often available where people really care about time stamp quality.

I was not suggesting changing the 'default' time stamp definition of
pcapng, but rather adding an option for the interpretation to be e.g. 'TAI'
rather than 'POSIX/Windows UTC' encoding for clarity.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150826/e0df9f94/attachment-0001.html>