Subject: [Tzdist] example json snips for systems that count leap seconds

From: Steve Allen <[email-masked]>
Date: Thu, 8 Jan 2015 22:36:19 -0800

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                 <[email-masked]>                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

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 13 Jan 2015 20:43:55 +0100

> information which is currently handled by the "right" zones of the IANA

I'm actually pretty busy writing emails to different mailing lists, news 
groups, and customers to explain details of leap seconds. ;-)

So I have to admit that recently I haven't followed the tzdist 
discussions very closely. Anyway, I've just had a look at Steve's JSON 
examples.

Please keep in mind my original intend was to get a list of leap second 
events and an associated expiration date via the tzdist protocol, so 
this information can be used for a number of different things, including 
letting NTP and PTP servers become aware of upcoming leap seconds, do 
UTC-TAI conversions, etc. In this context the "right" timezones are just 
one more application for this leap second table.

I think for the purpose mentioned above the most appropriate format is 
TAI-UTC.json.

 From my own experience I'd say an application programmer who is just 
interested in an enumeration of leaps second events would expect to see 
dates like

   2015-07-01T00:00:00Z

instead of

   2015-07-01T00:00:36Z

for the leap second events. However, if it's made clear that the times 
are TAI, not UTC (is 'Z' correct, then?) this should be no problem. The 
most important thing is that list of leap second events can be extracted 
properly.

Martin

---

From: Steve Allen <[email-masked]>
Date: Tue, 13 Jan 2015 12:35:14 -0800

On Tue 2015-01-13T20:43:55 +0100, Martin Burnicki hath writ:
> However, if it's made clear that the
> times are TAI, not UTC (is 'Z' correct, then?) this should be no
> problem. The most important thing is that list of leap second events
> can be extracted properly.

Martin is right, the 'Z' is an abuse of the notation.  The
interpretation that UTC might be counted without counting the leap
seconds is a different kind of abuse, but thinking of things in that
way is continuing a long-term non-constructive temporal flame war.
I am aiming to follow the lead of the "right" TimeZone database with
practical examples helping people to use tzdist in order to work
around deficiencies in the existing standards.

So as Martin cautioned, in the text (before the json examples that I
posted) it was necessary that I very clearly defined the assumptions
of each underlying system time scale including the way in which it
differs from various standards and the motivation for each difference.
With that documentation clearly explaining the appropriate context for
the use of each, the json examples that I posted should work with the
math of the code in existing calendar APIs.

---

From: Paul Eggert <[email-masked]>
Date: Tue, 13 Jan 2015 13:43:00 -0800

On 01/13/2015 11:43 AM, Martin Burnicki wrote:
> interested in an enumeration of leaps second events would expect to 
> see dates like
>
>   2015-07-01T00:00:00Z
>
> instead of
>
>   2015-07-01T00:00:36Z
>
> are TAI, not UTC (is 'Z' correct, then?)

I don't think it's correct.  TAI is not connected to the rotation of the 
earth, so it's misleading to say that TAI has days or dates. The IERS 
uses UTC or JD for dates and times of leap seconds, and we should do the 
same.  UTC is better than JD, as UTC is better-known among non-astronomers.