On 2020-11-12 18:11, Guy Harris wrote:
On Nov 12, 2020, at 10:02 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
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_utc...
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? I don't know whether it's documented anywhere, but:
"right" is intended to support converting times that are represented as seconds that have elapsed since January 1, 1970, 00:00:00 UTC - as opposed to be represented as "seconds since the Epoch", which means "seconds *except for leap seconds* that have elapsed since January 1, 1970, 00:00:00 UTC" - to year/month/day/hour/minute/second.
I.e., that's a counter that started as 0 on January 1, 1970, 00:00:00 UTC, and that increments by 1 every second, rather than getting adjusted to conform to POSIX.
gmtime() would convert such a time to UTC, with "second" possibly being > 59.
To explain my understanding of the "right" tzdb data, some context is needed. The definition of UTC states that the offset UTC - TAI is a piecewise constant function of TAI (for TAI >= 1972-01-01 + 10 s). This is similar to a tzdb Zone time scale Z, where the offset Z - UTC is also a piecewise constant function (but this time, of UTC). In this way, UTC is _defined_ (by the ITU and most recently by the CGPM) like a tzdb Zone time, except that it is based on TAI and not on UTC. For the specification of UTC, however, the values of TAI - UTC are given (for instance by the IERS and the BIPM) as a function of UTC, not of TAI; hence, _as specified_, it is TAI that really is like a tzdb Zone time scale based on UTC, the same base as for all the (non-"right") tzdb Zones. The computing interfaces for tzdb data typically allow for the conversion between datetimes of UTC and datetimes of any tzdb Zone time. The conversion from datetimes of UTC into the datetime of a tzdb Zone time for the same instant is uniquely defined by the tzdb data. The converse conversion, from a datetime of a tzdb Zone time scale to a corresponding datetime of UTC for the same instant, is not so well defined since there may be no such corresponding datetime of UTC, or there may be two such. Different tzdb interfaces give various amounts of information about such cases; the behaviour ranges from no information with an unspecified choice of values up to complete information (as eg with the function convertLocalToUtc() of the Bloomberg TimeZoneUtil library). Considering TAI (since 1972-01-01 + 10 s) as a tzdb Zone time reflects exactly what is specified by the IERS about the relationship of TAI with UTC. The conversion from a UTC datetime to a corresponding TAI datetime is uniquely defined by the IERS data; the converse conversion from TAI to UTC is not, and the computing interface should give enough information for handling (positive or negative) leap seconds in UTC as desired. As far as I understand the "right" tzdb data, they express the offsets of tzdb Zone time scales as functions of TAI - 10 s (not of UTC), and they include a Zone time scale for UTC, with the offset from TAI - 10 s again expressed as a function of TAI - 10 s. This does not reflect how the offsets from UTC are specified for TAI and all the local civil time scales (viz, as functions of UTC, and not of TAI), it requires extensions in the computing interface for tzdb data, it may give wrong conversions from UTC to TAI - 10 s around leap seconds, and requires a complete change of _all_ the "right" tzdb data whenever a new leap second becomes known. HTH. Michael Deckers.