Based on the work that Ken Murchison put into his example server at URLs
https://cyrus-test.andrew.cmu.edu/tzdist/zones/Etc%2FTAI
https://cyrus-test.andrew.cmu.edu/tzdist/zones/Etc%2FTAI/observances?start=1970-01-01T00:00:00Z&end=2038-01-01T00:00:00Z
I submit more examples of how tzdist could transport the same sort of
information which is currently handled by the "right" zones of the IANA
tzdata and tzcode.

Ken's example shows how a system which has its system clock set to UTC
could compute TAI as a time zone.  With added complexity in the client
code for tzdist this would already be enough information to compute
the value of TAI, but that added code complexity would be required in
order to represent times like 23:59:60.

Nevertheless, I think that the tzdist protocol already allows even a
client which does not have extra code to compute the values correctly
at all times other than during leap seconds.

Also, there exist POSIX systems whose value of time_t does not conform
to the specification.  They count every leap second.  For the sake of
my examples I describe three such leap-counting versions of time_t

1) time_t is set such that using the POSIX routines gives the
formatted time as TAI.  This TAI value is as defined by BIPM.

2) time_t is set such that using the POSIX routines gives the
formatted time as GPS system time.  This GPS value is as defined
in IS-GPS-200.

3) time_t is set such that using the POSIX routines gives the
formatted time as UTC from 1970-01-01 until the first leap second
on 1972-06-30.  After that all leap seconds are counted such that its
time_t would currently be 25 s larger than POSIX says it should be.
Subsequent to 1972 this system time is the same as (TAI - 10 s).  This
is the time_t value expected by the "right" zones in the IANA tzdata
and tzcode.  Although there is no explicit definition for such a time
scale it is "right" in the sense that it has counted every second
which has been broadcast by transmitters which have been following the
international recommendations.  (A practical means by which such a time
could have been maintained would be a receiver based on the LORAN-C
transmissions and using their "Time of Convergence" points to establish
the count of seconds, then at the retirement of LORAN-C replacing that
original receiver with a GPS-based unit that provides the same TAI - 10)

With that explained, the attached files have these names

TAI-UTC.json
shows how a system clock set to TAI could produce formatted output of
UTC.

GPS-UTC.json
shows how a system clock set to GPS could produce formatted output of
UTC.

Right-UTC.json
shows how a system clock set to "right" time could produce formatted
output of UTC.

Right-TAI.json
shows how a system clock set to "right" time could produce formatted
output of TAI.  (This one is entirely trivial.)

RightNew_York.json
shows how a system clock set to "right" time could produce formatted
output of New York time.  This should be equivalent to what is
contained in binary version of the "right" zone for New York.
(I've truncated this rather than hand compute all the transitions.)

In the ideal case a tzdist client with extra code to handle leap
seconds would simply choose the one of TAI-UTC, GPS-UTC, or Right-UTC
which is best suited to its system clock.  This would get it from
internal system time to UTC.  Then such a client would also use tzdist
to get the America/New_York data and compute its local time zone.

In the case of a tzdist client without code to handle leap seconds,
but with an internal system clock that is counting them, it would
choose RightNew_York and that would enable it to produce formatted
output that corresponds to its local time zone.

I am not representing any of these zone names as canonical.
If such zones are officially recognized then they will need
a suitable name space with very clear descriptions of the
circumstances where they are appropriate to use.

Note that while I use the notions of POSIX time_t and epoch (because
they are inherent in the tzcode) there is nothing about these files
which restricts them to being used by POSIX systems.

Also, the Chinese BeiDou satellite system and the Indian navigational
satellite system each have their own uniform time scale akin to those
I have used in the examples.  Files akin to the ones I attach could
equally well be used for system time based on transmissions from those.

--
Steve Allen                 <sla@ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m