[tz] What's "right"?

[John Haxby]

> On 12 Nov 2020, at 18:02, Paul Gilmartin via tz <tz at iana.org> wrote:
> 
> Hello, TZ,
> 
> In: ftp://ftp.iana.org/tz/tz-link.html
> I read:
>    The tz code and data support leap seconds via an optional
>    "right" configuration, ...
> 
> Empirically, this seems to assume time_t of TAI-10.  This isn't
> GPS, which I understand to be TAI-19:
>    http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_utcgpsglo_TAR15.pdf
> 
> TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock.
> 
> I find a couple references to "zoneinfo/right" in Makefile and NEWS.
> Is there more complete documentation of "right" and its rationale
> elsewhere?


What's missing, I think, from the other replies is the reason the Posix epoch is only approximately 1970-01-01 00:00:00.

It's because Posix explicitly defines a day to be 86400 seconds so that, basically, a programmer that wants "this time tomorrow" can just do "time(0) + 86400" and not worry about it.   The choice, I think, was between fixing all existing programs to go via a struct tm and, to not put too fine a point upon it, "lying".   ("Fixing" a kernel would have been interesting.)

Of course, it gets messy with having, for example, the last second of the year twice and code that cares about the encore second has to work hard to deal with it.   The consequences have been quite far reaching from that original decision: it's one of the reasons clock_gettime() has clocks for finding out whether it's time for lunch and clocks for determining how long lunch actually lasted.   Less prosaically, it's why at least one program that used getttimeofday() as an interval timer panicked when an sub-second interval not so much short as negative.  (The bug is now fixed, but the hideous workarounds are still being employed because no one is sure if it is actually fixed and no one wants to find out one dark and stormy night.)

jch