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

[Guy Harris]

On Aug 25, 2015, at 2:12 PM, Stephen Donnelly <stephen.donnelly at avagotech.com> wrote:

> Time stamps are noted as being in UTC, so presumably if_tzone is just a display hint?
> 
> UTC is arguably not the ideal time base for packet traces or statistics, as there are (leap) seconds occasionally with no valid UTC value.

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.

And, if a negative leap second is "inserted", i.e. a second is removed from the day, UTC goes from 23:59:58 to 00:00:00 the next day (or, for two negative leap seconds, from 23:59:57 to 00:00:00 the next day).

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.

(Yes, this means that POSIX systems don't provide UTC.  They really don't.

A system that explicitly rejects 100% POSIX compliance by having the system clock tick one second at a time, *even for leap seconds*, and that uses the IANA time zone database, complete with the leap second tables, in gmtime(), using the leap second tables the same way the IANA time zone sample code does, *does* provide UTC.)

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.