Subject: [Tzdist] [tzdist] #34 (service): should we include a raw tzdb format media type?

From: "tzdist issue tracker" <[email-masked]>
Date: Wed, 07 Jan 2015 21:21:38 -0000

#34: should we include a raw tzdb format media type?

 I am not fully convinced that this needs to be done in this draft, but I
 do think it would be a good idea to support the raw format, so that simple
 systems don't need to do the recompile.  An iPhone will not be the
 smallest system to run this code, we hope.

 In favor of putting the media type in the draft is that we can test
 whether multiple formats can in fact be supported.  The bad is that it
 could slow us down just a little, and I would rather not include anything
 for which there isn't a willingness by someone to write out some code on
 both ends to test.

 It is possible to include this as a separate draft, but we need to be very
 comfortable that we haven't made a mistake draft-ietf-tzdist-service that
 would cause a problem.  So for instance, those files normally come over at
 the level of a continent.  What would a query look like?

 Let's discuss.

-- 
--------------------------------+------------------------------
 Reporter:  [email-masked]      |      Owner:  [email-masked]
     Type:  defect              |     Status:  new
 Priority:  minor               |  Milestone:
Component:  service             |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/34>
tzdist <http://tools.ietf.org/tzdist/>

---

From: Paul Eggert <[email-masked]>
Date: Wed, 07 Jan 2015 15:54:11 -0800

tzdist issue tracker wrote:
> those files normally come over at

The tz binary format is specified per name, e.g., there's a separate file in tz 
binary format for 'America/Los_Angeles'.  This is the same as the VTIMEZONE 
format, so presumably a query would look just like the query for the VTIMEZONE 
format, except that it's ask for tz binary format instead of VTIMEZONE format.

I don't see how continents are involved with this, other than as strings that 
appear as part of the name strings.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Jan 2015 06:29:42 +0100

I stand corrected.  Paul's right.  I was thinking of the source file.

Eliot

On 1/8/15 12:54 AM, Paul Eggert wrote:
> The tz binary format is specified per name, e.g., there's a separate
> file in tz binary format for 'America/Los_Angeles'.  This is the same
> as the VTIMEZONE format, so presumably a query would look just like
> the query for the VTIMEZONE format, except that it's ask for tz binary
> format instead of VTIMEZONE format.
>
> I don't see how continents are involved with this, other than as
> strings that appear as part of the name strings.
>
>

---

From: Lester Caine <[email-masked]>
Date: Thu, 08 Jan 2015 10:08:00 +0000

> I stand corrected.  Paul's right.  I was thinking of the source file.

Not having actually looked at the binary tz setup - I still work with
the raw data files - I'm not sure if each TZid has it's own full
expansion from the base generic rules? Is that the case Paul?

With large areas of the world NOW using a generic rule, one of the
American areas, or European time, I can envisage a 'distributor' that
provides only a current subset of timezone data? Perhaps even truncated
to 2010 and used for ICALENDAR/IEVENT current events. In much the same
way that the mechanism for monitoring 'version' comes out in the wash,
one that maps TZid to the core generic rules should also come out
naturally?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Paul Eggert <[email-masked]>
Date: Thu, 08 Jan 2015 08:12:31 -0800

Lester Caine wrote:
> I'm not sure if each TZid has it's own full

Yes and no.  There are separate files for America/Los_Angeles, Europe/Paris, 
etc.  But there are merely links for aliases.

---

From: Lester Caine <[email-masked]>
Date: Thu, 08 Jan 2015 16:52:33 +0000

On 08/01/15 16:12, Paul Eggert wrote:
> Yes and no.  There are separate files for America/Los_Angeles,
> Europe/Paris, etc.  But there are merely links for aliases.

But there will be separate files for many aliases which are now all
following the same generic rule - even after the cull for 1970 cut-off,
some files still have pre-1970 only differences? Which would be
different again with a later truncation point?

---

From: Tim Parenti <[email-masked]>
Date: Thu, 8 Jan 2015 13:21:26 -0500

> Europe/Paris, etc.  But there are merely links for aliases.

To expound a bit here, with the exception of links for aliases, TZ binary
files can stand on their own and are not dependent on one another.  The
encoding for each file contains each individual transition point for that
zone, what we would probably call an "expansion" in tzdist parlance.  Once
compiled down to the binaries, there is no notion of zones sharing rules.

> different again with a later truncation point?

I think the truncation discussion is strictly orthogonal to this issue.

That said, if a user requests a TZ binary file for a zone identifier which
is simply an alias, such as US/Eastern, I think it would be perfectly
reasonable for the server to return the corresponding file for the linked
zone — in this case, America/New_York.  Whether the response should also
include some note about the "canonical" zone name, I'm not sure.

--
Tim Parenti

---

From: Ken Murchison <[email-masked]>
Date: Thu, 08 Jan 2015 13:34:50 -0500

On 01/08/2015 01:21 PM, Tim Parenti wrote:
>
> That said, if a user requests a TZ binary file for a zone identifier 
> which is simply an alias, such as US/Eastern, I think it would be 
> perfectly reasonable for the server to return the corresponding file 
> for the linked zone — in this case, America/New_York. Whether the 
> response should also include some note about the "canonical" zone 
> name, I'm not sure.

For iCalendar data we note the "canonical" zone name by including a 
TZID-ALIAS-OF property in the data.

I'd have to look at RFC7231 to see if this is sane/legal, but an option 
for indicating the "canonical" zone name when fetching binary data for a 
linked zone might be to include a Content-Location response header with 
the URL to the "canonical" zone.

Another option would be to redirect a request for a linked zone (with 
the appropriate 3xx response code) to the "canonical" zone.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

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

On 8 January 2015 at 13:34, Ken Murchison <[email-masked]> wrote:

>> which is simply an alias, such as US/Eastern, I think it would be perfectly
> linked zone might be to include a Content-Location response header with the
> URL to the "canonical" zone.
>
> Another option would be to redirect a request for a linked zone (with the
> appropriate 3xx response code) to the "canonical" zone.

I think that any of these solutions could be acceptable.  I'm not familiar
enough with the intricacies of each to prefer one over the others at this
point.

--
Tim Parenti

---

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

As for my actual thoughts on this matter...

On 7 January 2015 at 16:21, tzdist issue tracker <[email-masked]
> wrote:

>  smallest system to run this code, we hope.

+1 to all of the above; as Paul discussed at
http://www.ietf.org/mail-archive/web/tzdist/current/msg01192.html, the raw
tz binary is an existing lean format with several potential performance
benefits for small clients.

>  would cause a problem.

Wouldn't this slow us down a bit either way?  Both approaches would require
taking the time to write a spec for the format, and then adding it to
-service either directly or by reference.  I'm not sure which approach is
typically better in practice.

I recognize this might be a bit of "scope creep" for this working group,
but if we limit ourselves to simply describing the format as it already
exists, it shouldn't be too bad or set us back by much.  If this is to
happen, I think the folks at tz should at least be included at some point
in the process.  (It is a tz format, after all.)

This is my first working group, so I'm not too familiar with the process
for finalizing drafts, but if others agree that this shouldn't block us in
the meantime, I don't think it should either.

--
Tim Parenti