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

[Guy Harris]

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

> 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

No.

The current spec says

	The timestamp is a single 64-bit unsigned integer representing the number of units since 1/1/1970 00:00:00 UTC.

It doesn't say "units *except for those evil leap seconds!!!!!111ONE!!!!!!*", so I'd say "it counts up once per unit, every unit" - i.e., *not* POSIX/Windows-style - is a valid interpretation.

> or does the reference to UTC imply that the time stamps are monotonic?

The reference to UTC doesn't.  POSIX time refers to UTC, but it's not monotonic.

The "number of units" could be viewed as implying a simple monotonic counter.

> 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.

There's "time stamps" in the sense of "real-number coordinates on an axis with a given origin", and there's "time stamps" in the sense of "stuff a normal human would recognize as a date and time".

Most if not all capture files, including pcap and pcapng, provide time stamps that are approximations of the first of those senses; it's the capture file readers that turn them into values of the second type.

ITU-R Recommendation TF.460-6:

	http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf

says that TAI "is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971)."  Presumably it could also be presented as "seconds from the origin 1 January 1958" (presumably "the origin 1 January 1958" represents a particular time of day *on* 1 January 1958), as well as YYYY-MM-DD HH:MM:SS, with SS always going from 0 to 1 to 2 to ... to 57 to 58 to 59 to 0 in the next minute (with further carry propagation as necessary).

It says that UTC "corresponds exactly in rate with TAI but differs from it by an integer number of seconds." and also says:

	A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).

so, if represented as YYYY-MM-DD HH:MM:SS, UTC could have SS jump from 58 to 0 of the next minute or from 59 to 60 to 0 of the next minute (again, with further carry propagation as necessary).

The "difference" between TAI and UTC is the difference between, for example, two Julian day number/HH:MM:SS values; for any given time, the HH:MM:SS values will differ (and the Julian day numbers will differ for a few seconds around the end of the day as well) due to the TAI HH:MM:SS values going, on some occasions, from 23:59:59 to 00:00:00 on the next day and the UTC values, on those same occasions, going from 23:59:59 to 23:59:60 to 00:00:00.

If both TAI and UTC were represented as seconds that have elapsed since their individual epochs, the difference between those representations would be a constant (the difference between their epochs, if any), unaffected by leap seconds, and either one would work as a monotonic count of seconds; it's attempting to tie a monotonic counter to the rotation of the earth that causes the problem.

> 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.

Unfortunately, given the hardware and software on which most captures are done, it's probably not an interpretation that would allow a valid interpretation of the time stamp values.

So, if we're to allow packet captures on UN*X and Windows systems, with OS-supplied time stamps, we'd have to find *some* way to describe POSIX-style time stamps.

If a "unit" is 1 second, then we could go with POSIX.

However, if it's less than 1 second, what happens during a leap second?  Does the counter keep ticking milliseconds or microseconds or nanoseconds or whatever, and then reset back to the beginning of the previous second?