Subject: [calsify] Timezone service draft

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Nov 2012 11:05:02 -0500

Hi folks,
We have posted a new version of the timezone service draft: 
<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/> and 
would greatly appreciate reviews of this as we intend to ask the IETF/IESG 
to start the process of review/approval/publication.

There has been one big change in this new version: the switch to using JSON 
for the responses from the server rather than XML. This was something we 
had been considering for a while - primarily because we think the most 
common "light weight" clients wanting to use this protocol will be 
web/browser based.

-- 
Cyrus Daboo

---

From: Steve Allen <[email-masked]>
Date: Fri, 30 Nov 2012 11:57:24 -0800

On Fri 2012-11-30T11:05:02 -0500, Cyrus Daboo hath writ:
> <https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>
> and would greatly appreciate reviews of this as we intend to ask the
> IETF/IESG to start the process of review/approval/publication.

I do not find that the draft contains any mechanism for distributing
the content of the leapseconds file which is part of the IANA time
zone database.

It is currently the case that the UTC time scale is defined by ITU-R
recommendation TF.460-6 which is available at
http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
It looks as if in this internet draft the connection to the definition
of UTC is via RFC 5545 which references ISO 8601 which references the
defining documents and responsible agencies for UTC.

As of February 2012 the ITU-R had issued
Administrative Circular CA/201
http://www.itu.int/md/R00-CA-CIR-0201/en
in which Resolution 653 [COM6/20] (WRC-12) was designated as
WRC-15 Agenda item 1.14.  That calls upon its working party to remain
engaged in a process which may result in a redefinition of UTC and/or
of the broadcast time scale which underlies the implementation of
clocks in computing systems.

It is clearly not possible for this draft to include the results of
ITU-R decisions which will not be made until year 2015.  It is clear
that any result from the ITU-R, and the reactions of governmental
agencies responsible for local times, will be consistent with the
current contents of IANA tz/zoneinfo database -- if the leapseconds
file is included as part of the scheme.

The current draft has section "4.1.7.  Extensions" which will allow
for subsequent inclusion of the data from the leapseconds file.  The
usual pattern from the ITU-R is to allow a five year period between
announcement of change and implementation of change.  Nevertheless, if
the information in the leapseconds file can be included into the
protocols of this internet draft then standards bodies and developers
will be much less rushed to implement any change that may be decreed.

--
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: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Nov 2012 15:35:45 -0500

Hi Steve,

> the content of the leapseconds file which is part of the IANA time

Correct - however, calendaring and scheduling clients (which are the ones 
we are initially targeting for this service) don't need leap second 
information as they typically rely on  OS level time apis to get UTC or 
local time.

That said, in the longer term we would like to see this service being used 
to distribute the equivalent of "zoneinfo" files (or something easily 
converted into zoneinfo) - doing that will likely involve developing a more 
"generic" format for timezone data (e.g., a JSON representation of IANA 
tzdb). At that point, a way to get the leap seconds list would be good too.

So yes leap seconds are not available, but I don't believe that is a 
handicap for the initial target audience. We have designed the protocol to 
be extensible so adding leap seconds is easy after the fact.

-- 
Cyrus Daboo