Subject: [Tzdist] #10 We should truncate (entirely) truncation ;-)

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Sep 2014 17:05:40 +0200

Hi,

Before we close #10 [1], I would like to make sure we have consensus with
Truncation Time Zone section 3.4. [2].

3.4 <http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-3.4>.
Truncating Time Zones

   Time zones and daylight saving times rules have been in use for over
   a century.  Time zone data can thus contain a large amount of
   "historical" information that may not be relevant for a particular
   server's intended clients.  For example, calendaring and scheduling
   clients are likely most concerned with time zone data that covers a
   period for one or two years in the past on into the future, as users
   typically create only new events for the present and future.
   Similarly, time zone data might contain a large amount of "future"
   information about transitions occurring many decades into the future.
   Again, clients might be concerned only with a smaller range into the
   future, and data past that point might be redundant.

   To avoid having to send unnecessary data, servers are allowed to
   truncate time zone data to a range determined by start and end point
   date and time values, and provide only offsets and rules between
   those points.  The server will need to advertise the ranges it is
   using so that clients can take appropriate action if they need time
   zone data for times outside of those ranges.

   The truncation points at the start and end of a range are always a
   UTC date-time value, with both points being "inclusive" to the
   overall range.  A server will advertise a truncation range for the
   truncated data it can supply, or provide an indicator that it can
   truncate at any start or end point to produce arbitrary ranges.  In
   addition, the server can advertise that it supplies untruncated data
   - that is data that covers the full range of times available from the
   source publisher.  In the absence of any indication of truncated data
   available on the server, the server will supply only untruncated
   data.

   When truncating the start of a "VTIMEZONE" component, the server MUST
   include either a "STANDARD" or "DAYLIGHT" sub-component with a
   "DTSTART" property value that matches the start point of the
   truncation range, and appropriate "TZOFFSETFROM" and "TZOFFSETTO"
   properties to indicate the correct offset in effect right before and
   after the truncation range start point.  This sub-component, which is
   the first observance defined by the time zone data, thus represents
   the earliest valid date-time covered by the time zone data in the
   truncated "VTIMEZONE" component.

   When truncating the end of a "VTIMEZONE" component, the server MUST
   include a "TZUNTIL" iCalendar property (Section 8.1
<http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-8.1>)
in the
   "VTIMEZONE" component to indicate the end point of the truncation
   range.

[1] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/10
[2] http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-3.4

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tobias Conradi <[email-masked]>
Date: Wed, 24 Sep 2014 19:42:39 +0200

> Truncation Time Zone section 3.4. [2].
I would follow Eliot and truncate the section, but not entirely.

>    "historical" information
Only that TZ and DST is in use doesn't mean there is a large (what is
large?) amount of data.

Furthermore ' "historical" information ' is unclear.

OLD
Time zones and daylight saving times rules have been in use for over
a century.  Time zone data can thus contain a large amount of
"historical" information that may not be relevant for a particular
server's intended clients.

NEW
Time zone data can contain information about past and future UTC offsets
that may not be relevant for a particular server's intended clients.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tim Parenti <[email-masked]>
Date: Wed, 24 Sep 2014 14:21:57 -0400

> Truncation Time Zone section 3.4. [2].

To clarify, you're asking whether we approve of the text of 3.4 as written
in the current draft 01?

--
Tim Parenti

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Sep 2014 21:22:58 +0200

yes, that's it.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Thu, 25 Sep 2014 00:21:58 +0100

> that may not be relevant for a particular server's intended clients.

This simplification makes sense.
The details of the complications of both historic and future data
composition is covered by the TZ database documentation and any third
party publisher would be expected to detail their own provenance?

However something which may be a more useful truncation is not the time
period, but the TZID set. A lightweight secondary server could get away
only serving a single TZID which would be obvious from the 'list'
return, but it would be better if the "truncated" capability data had an
option for "restricted" which would be the number of TZID's being
served. This solves a problem with the building control server scenario
where other computers on the buildings network may pick up the local
server, and that server does not have to support a comprehensive data set.

-- 
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: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 10:51:59 -0400

Hi Lester,

> server, and that server does not have to support a comprehensive data set.

So you want a way for a secondary server to advertise that it is only 
making available a subset of tzdata/tzids from a primary?

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 26 Sep 2014 18:38:46 +0200

On Fri, Sep 26, 2014 at 4:51 PM, Cyrus Daboo <[email-masked]> wrote:
> So you want a way for a secondary server to advertise that it is only making
> available a subset of tzdata/tzids from a primary?
The protocol does not mandate any database.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Sep 2014 12:53:51 -0400

Hi Lester,

> This simplification makes sense.

I think most people are in agreement with this new wording so I will make 
the change in my working copy.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Fri, 26 Sep 2014 19:33:34 +0100

> making available a subset of tzdata/tzids from a primary?

Essentially yes. But I think I superseded it by the idea of a URL that
simply returns a single TZID offers an alternate way of managing a local
network of simple client devices. It should still identify that the list
is only returning a single TZID for that reason just in case a client
tries to use it when it expects a full data set.

You don't like Stephen's view of how url's might work, but a /default/
in parallel with the /latest/ makes perfect sense. And adding the
version selection here completes the jigsaw without adding any overhead
to the basic standard.