Subject: [Tzdist] futureproofing for leap seconds

From: Steve Allen <[email-masked]>
Date: Tue, 19 Aug 2014 13:33:18 -0700

I remain concerned that the draft-douglass-timezone-service document
should provide a way to communicate the information which is currently
contained in the tz file named "leapseconds".

The ITU-R continues to study questions about the future of the
international time scale.  After the 2012 Radiocommunications Assembly
declined to vote on the draft document which would have redefined UTC
without leap seconds they produced Resolution 653
http://www.itu.int/dms_pub/itu-r/oth/0c/0a/R0C0A00000A0022PDFE.pdf
That became WRC-15 Agenda Item 1.14, and ways to satisfy that
are being actively pursued in order to be done in time for the
World Radiocommunication Conference in late 2015.

Although the ITU-R process is not open, some glimpses of work on
Agenda Item 1.14 have been visible in drafts circulated from various
agencies who contribute to ITU-R.  Those show that three different
outcomes have been under consideration by the ITU-R.  Method A is to
abandon leap seconds in UTC, but this has failed to achieve consensus
for over a decade.  Method B is to distribute two time scales, one
with leap seconds and one without, but the BIPM objects to this.
Method C is not clear but seems to indicate that UTC would continue to
have leap seconds and that the ITU-R might take some other action.  In
short, there is no way yet to predict what the ITU-R will decide at
WRC-15.

With the status quo (which is something like what draft proposed
method C seems to imply) then if I am not mistaken the timezone
service response for the UK during 2012 would look something like this

{
  "name": "GMT",
  "onset": "2012-01-01T00:00:00",
  "utc-offset-from": 0,
  "utc-offset-to": 0
},
{
  "name": "BST",
  "onset": "2012-03-25T01:00:00",
  "utc-offset-from": 0,
  "utc-offset-to": +3600
},
{
  "name": "GMT",
  "onset": "2012-10-28T02:00:00",
  "utc-offset-from": +3600,
  "utc-offset-to": 0
},

If draft proposed method A had been adopted before 2012 and the UK had
decided to continue the practice of leap seconds then the example from
section 6.4.1 could handle UK civil time with a response that would have
looked something like this

{
  "name": "GMT",
  "onset": "2012-01-01T00:00:00",
  "utc-offset-from": 0,
  "utc-offset-to": 0
},
{
  "name": "BST",
  "onset": "2012-03-25T01:00:00",
  "utc-offset-from": 0,
  "utc-offset-to": +3600
},
{
  "name": "BST",
  "onset": "2012-07-01T01:00:00",
  "utc-offset-from": +3600,
  "utc-offset-to": +3599
},
{
  "name": "GMT",
  "onset": "2012-10-28T02:00:00",
  "utc-offset-from": +3599,
  "utc-offset-to": -1
},

Both of those outcomes are handled by the current draft.

The futureproofing problem comes if the ITU-R were to adopt draft
something like proposed method B.  In that case some platforms might
choose to keep their underlying system clock set to the old UTC with
leap seconds, and some platforms might choose to change their
underlying system clock to the newly-made-official TAI-like time
scale.  Furthermore, some jurisdictions might make similarly different
choices about the basis for their civil time.

If this were to happen then platforms using the protocol described in
this draft-douglass-timezone-service would need the information
contained in the tz "leapseconds" file in order to know how to
interoperate with other platforms and other jurisdictions.  (In
practice there are already some platforms which have adopted a
TAI-like underlying time scale, and they already could make use of a
reliable means to transport the information in the "leapseconds" file.)

It is clearly difficult merely to define a future-proofed vocabulary
for this protocol, but if the information in the tz "leapseconds" file
were distributed then the operational needs would be present and the
terminology could be clarified after the ITU-R makes its decision.

--
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: Steve Allen <[email-masked]>
Date: Tue, 19 Aug 2014 21:33:20 -0700

> contained in the tz file named "leapseconds".

Upon more thought, the current form of draft-douglass-timezone-service
looks like it can transfer the content of the tz "leapseconds" file if
TAI is regarded as a time zone.  This could probably serve the needs
of various platforms in various jurisdictions no matter what those
choose as the basis for their system and civil times and no matter
what the ITU-R decides to do at WRC-15.

Not encoded in this modifed example from section 6.4.1 is the date at
which a particular system might (have) decide(d) to switch from
counting mean solar seconds of UT to counting atomic seconds of TAI,
for that will likely differ from one platform and jurisdiction to
another.

  >> Request <<

  GET /?action=expand&tzid=Etc/TAI&start=1970&end=2014 HTTP/1.1
  Host: tz.example.com

  >> Response <<

  HTTP/1.1 200 OK
  Date: Mon, 11 Oct 2009 09:32:12 GMT
  Content-Type: application/json; charset="utf-8"
  Content-Length: xxxx
  ETag: "123456789-000-111"

  {
    "dtstamp": "2014-08-20T04:00:00Z",
    "observances": [
      {
	"name": "proleptic",
	"onset": "1970-01-01T00:00:00",
	"utc-offset-from": +10,
	"utc-offset-to": +10
      },
      {
	"name": "TAI-10",
	"onset": "1972-01-01T00:00:10",
	"utc-offset-from": +10,
	"utc-offset-to": +10
      },
      {
	"name": "TAI-11",
	"onset": "1972-07-01T00:00:10",
	"utc-offset-from": +10,
	"utc-offset-to": +11
      },
      {
	"name": "TAI-12",
	"onset": "1973-01-01T00:00:11",
	"utc-offset-from": +11,
	"utc-offset-to": +12
      },
      {
	"name": "TAI-13",
	"onset": "1974-01-01T00:00:12",
	"utc-offset-from": +12,
	"utc-offset-to": +13
      },
	etc until
      {
	"name": "TAI-31",
	"onset": "1997-07-01T00:00:30",
	"utc-offset-from": +30,
	"utc-offset-to": +31
      },
      {
	"name": "TAI-32",
	"onset": "1999-01-01T00:00:31",
	"utc-offset-from": +31,
	"utc-offset-to": +32
      },
      {
	"name": "TAI-33",
	"onset": "2006-01-01T00:00:32",
	"utc-offset-from": +32,
	"utc-offset-to": +33
      },
      {
	"name": "TAI-34",
	"onset": "2009-01-01T00:00:33",
	"utc-offset-from": +33,
	"utc-offset-to": +34
      },
      {
	"name": "TAI-35",
	"onset": "2012-07-01T00:00:34",
	"utc-offset-from": +34,
	"utc-offset-to": +35
      },
    ]
  }

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2014 11:00:13 +0200

Hi Steve,

> what the ITU-R decides to do at WRC-15.

I hope this is the case as well.  If it is not the case, then I would
suggest that the matter be discussed further where a schema extension
would be required.

Eliot