Subject: Re: [Tzdist] [tzdist] #31 (service): Include leap seconds?

From: Tim Parenti <[email-masked]>
Date: Sat, 10 Jan 2015 20:33:30 -0500

On 19 December 2014 at 12:23, Cyrus Daboo <[email-masked]> wrote:

> The alternative is to introduce a new JSON format for leapseconds that can
> be tailored for the exact schema we need:
>
> {
>  "start": "1972-01-01T00:00:00Z",
>  "end": "2015-06-28T00:00:01Z",
>  "changes":
>  [
>    {
>       "onset": "1972-01-01T00:00:00Z",
>       "offset": 10
>    },
>    {
>       "onset": "1972-07-01T00:00:00Z",
>       "offset": 1
>    },
>    ...
>    {
>       "onset": "2012-07-01T00:00:00Z",
>       "offset": 1,
>    }
>  ]
> }
>
> I think that is a little cleaner and it would avoid having to adapt the
> existing expand schema (and associated description). So I am going to
> propose we use a new JSON format for leapseconds (on the assumption that we
> can get quick consensus on that).
>

Has this been proposed?  On the call from 18 December 2014, I was in favor
of hanging this from /leapseconds with a new JSON format similar to our
expanded response for /zones/observances.  I don't think, however, that
offsets of ±1 are appropriate here, for two reasons:

   - /zones/observances refers to the offsets themselves and not changes in
   offset, and we should be consistent
   - truncated responses here would get a list of "1"s which doesn't
   provide the actual TAI–UTC value that might be more important to certain
   clients

So I think the values used here should be something like TAI–UTC values
instead.

On 23 December 2014 at 04:25, Daniel Migault <[email-masked]> wrote:

> I am just wondering whether having a single spec for distributing leap
> seconds and tz would not require that format must be valid for leap second
> and tz. I have no idea whether it is an awful idea or not, but maybe we
> could work around this issue with a separate document for "adaptation of tz
> dist service for leap seconds", making these two services independent.  --
> of course it could also be a section in the current document.

In most cases, it seems the protocol will be far simpler if we keep zone
transitions as separate from leap second transitions as possible.  So I
think leap seconds can simply be a section of the current document,
especially if we decide we're not blocking on #34 (tz binary format).

Only because the "right" versions of the tz binary files combine these two
things will we have to decide how to handle this when addressing #34.

--
Tim Parenti