[tz] What's "right"?

Guy Harris gharris at sonic.net
Sat Nov 14 06:06:03 UTC 2020

On Nov 13, 2020, at 7:38 PM, Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

> On Fri, Nov 13, 2020 at 4:12 PM John Haxby <john.haxby at oracle.com> wrote:
> If the wall clock time for the Unix Epoch is not the stroke of midnight -- it *moves*.   And it moves because a day is exactly 86400 seconds.  In the real world though there have been 27 (I think) days between the Posix Epoch and now where a day was 86401 seconds.
> If you use a right timezone on Linux then you have to live with minor but irritating problems with programs that implicitly assume the Posix day length.  For those applications that really don't work unless you're using a right/ timezone, that minor annoyance is a price worth paying.
> Most applications that are neither astronomical nor navigational find it convenient to treat the nominal time since epoch as
> "86400 times the number of days since 1 January 1970 + the number of elapsed seconds in the current day." The reason for ignoring leap seconds is that a great many applications deal with *civil* dates and times in the future, and it is impossible to predict more than a year or two in advance when a leap second might occur.

These days, most of my software work involves an application where the ideal time stamp is "seconds that have elapsed since the Epoch, *including* leap seconds", because

	1) users might want to know both 1) absolute times and 2) delta times in seconds


	2) times are 99.999999999999999999% likely to be times in the past, so there's no issue with the inability to predict leap seconds in the future.

That application is "capturing network packets and saving them to a file, and then analyzing those files", i.e., in my case, libpcap, tcpdump, and Wireshark.

It would be Very Nice Indeed if:

	packet capture mechanism could time-stamp packets with "seconds that have elapsed since the Epoch, *including* leap seconds";

	APIs existed to convert those time stamps to year/month/day/hour/minute/second/fraction of a second.

(Extra credit for those APIs being able to take a tzdb ID, or a handle returned by an API that takes a tzdb ID, so that if somebody wants to know what time it was in Berlin when the packets arrived, even if they're in Adelaide when they're analyzing the packets.)

(And, yes, that should also involve a way of indicating what type of time stamp packets received on a particular adapter, e.g. "POSIX timestamps" vs. "all seconds since the Epoch" time stamps", so the program know how to convert them to year/month/day/hour/minute/second/fraction.  I need to update the pcapng spec for that.)

That doesn't mean *all* APIs need to work that way - just provide, in addition to APIs using POSIX time stamps, APIs using "all seconds since the Epoch" time stamps.  (One possibility would be to have the "take a tzdb ID and return a handle" API also take an indication of whether time stamps should be treated as POSIX or "all seconds since the Epoch"; "if the tzdb ID has right/ prepended to it, it's all seconds since the Epoch, otherwise it's POSIX time" is one option.)

This provides a clock that, as long as the clock is adjusted by doing adjtime()-style adjustment (don't turn the clock forward, temporarily speed it up until it's where you want it to be, and don't turn the clock backward, temporarily slow it down until it's where you want it to be), is monotonic, and that, modulo the clock being off, can be used to compute time deltas between packets without leap seconds causing incorrect deltas.

(It's better if the packet gets time stamped on arrival as close either to the time the first bit appears or the time the last bit appears, and time stamped on transmission as close either to the time the first bit is put on the wire or the time when the last bit is put on the wire, which probably requires adapters that can do that.)

More information about the tz mailing list