[tz] What's "right"?

[Michael H Deckers]

   On 2020-11-12 18:11, Guy Harris wrote:
> On Nov 12, 2020, at 10:02 AM, Paul Gilmartin via tz <tz at 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_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?
> 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.