[tz] What's "right"?
Michael H Deckers
michael.h.deckers at googlemail.com
Fri Nov 13 13:17:58 UTC 2020
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:
>> 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
> 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
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
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
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.
More information about the tz