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

From: Daniel Migault <[email-masked]>
Date: Sat, 1 Nov 2014 15:11:47 +0100

Dear Friends and Colleagues,

As none raised any issue with the text, I assume it has reached consensus.
I will close Issue # 10 next week.

BR,
Daniel

On Thu, Oct 23, 2014 at 5:27 PM, Daniel Migault <[email-masked]> wrote:

> Dear Friends and Colleagues,
>
>
> The proposed text for version 02 is:
>
>    To avoid having to send unnecessary data, servers can choose 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.  If such truncation is done, the server MUST include
>    the ranges it is using in the "capabilities" action response (see
>    Section 7.1 <http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-7.1>), so that clients can take appropriate action if they
>    need time zone data for times outside of those ranges.
>
> Do we have agreement with this text?
>
> BR
>
> Daniel
>
>
>
> On Thu, Oct 2, 2014 at 1:10 AM, Tim Parenti <[email-masked]> wrote:
>
>> On a similar point, elsewhere in 3.4 we have:
>>
>> CURRENT:
>>
>> 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.
>>>
>>
>> It's not clear to me what it means to "advertise the ranges".  I'm
>> assuming we mean that the servers must include notice of the truncation
>> ranges it is using in any response it gives.  Perhaps we should make that a
>> bit stronger?
>>
>> PROPOSED:
>>
>> To avoid having to send unnecessary data, servers MAY elect 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.  If such
>>> truncation is implemented, the server MUST include the ranges it is using
>>> within its responses, so that clients can take appropriate action if they
>>> need time zone data for times outside of those ranges.
>>>
>>
>> --
>> Tim Parenti
>>
>> On 26 September 2014 12:53, Cyrus Daboo <[email-masked]> wrote:
>>
>>> Hi Lester,
>>>
>>> --On September 25, 2014 at 12:21:58 AM +0100 Lester Caine <
>>> [email-masked]> wrote:
>>>
>>>  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.
>>>>>
>>>>
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> Tzdist mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tzdist
>>>
>>
>>
>> _______________________________________________
>> Tzdist mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tzdist
>>
>>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>

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

---

From: Lester Caine <[email-masked]>
Date: Sat, 01 Nov 2014 15:13:51 +0000

On 01/11/14 14:11, Daniel Migault wrote:
> As none raised any issue with the text, I assume it has reached
> consensus. I will close Issue # 10 next week.

Can I just clarify what a request that attempts to use a timespan
outside that the server has published in it's capabilities? In light of
some of the other developments, I think a few things need redefining.

'expand' works nicely since it has invalid-start and invalid-end and
they can be limited by the published range, but 'get' also needs the
same errors now? Then having two different range settings seems a little
inconsistent? <truncate> on one and <start> and <end> on the other.

In this situation is truncate still optional? Or should it 'default' to
the published range? I think I then assuming that DTSTART and TZUNTIL
will mirror those values back?

On expand, end is optional, but a value of 10 years may take it outside
the published time span and in that case I assume there is currently no
indication if the rule set terminated earlier?  I think that an
equivalent to TZUNTIL may be needed here what ever the reason for the
truncation?

-- 
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: Tim Parenti <[email-masked]>
Date: Mon, 3 Nov 2014 14:26:13 -0500

On 23 October 2014 11:27, Daniel Migault <[email-masked]> wrote:

> If such truncation is done, the server MUST include
>    Section 7.1 <http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-7.1>)
>
>
Sorry, this got lost in the pre-conference call avalanche of emails from
which I am slowly recovering.

It was the intent of my proposal (
http://www.ietf.org/mail-archive/web/tzdist/current/msg00706.html) that the
truncation ranges be specified in the individual responses themselves, so
that the client has all of the metadata about the data it is receiving in
one response.  For JSON, this would require an additional field or two.
For iCalendar VTIMEZONEs, this could probably be handled by TZ-UNTIL and
the like.

I think it's reasonable to also include this in the "capabilities"
response, but I think that, if truncation is used, each individual response
should carry this information as well.

--
Tim Parenti

---

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Nov 2014 12:28:47 +0100

Dear friends and Colleagues,

We are asking the WG whether this issue has been addressed by
draft-ietf-tzdist-service-03
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03>. Feel free to
give your opinion by Friday 21, so we can cleanup the open issue and focus
our attention on issues that have not been solved yet.

BR,
Daniel

The proposed text is as mentioned below:

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

   Time zone data can contain information about past and future UTC
   offsets 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 can choose 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.  If such truncation is done, the server MUST include
   the ranges it is using in the "capabilities" action response (see
   Section 6.1 <http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-6.1>),
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 7.1
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-7.1>)
in the
   "VTIMEZONE" component to indicate the end point of the truncation
   range.

PS: Issues expected to be addressed by this version are tracked by the
Issue Summary
<http://www.ietf.org/mail-archive/web/tzdist/current/msg00913.html>,

On Mon, Nov 3, 2014 at 8:26 PM, Tim Parenti <[email-masked]> wrote:

> http://www.ietf.org/mail-archive/web/tzdist/current/msg00706.html) that
> the truncation ranges be specified in the individual responses themselves,
> so that the client has all of the metadata about the data it is receiving
> in one response.  For JSON, this would require an additional field or two.

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

---

From: Lester Caine <[email-masked]>
Date: Tue, 18 Nov 2014 11:45:07 +0000

On 18/11/14 11:28, Daniel Migault wrote:
>       3.8
>       <http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-3.8>.
>       Truncating Time Zones

Linked to this

5.4 expand action
invalid-start  The "start" URI query parameter has an incorrect
value, or appears more than once, or is missing, or has a value
less than any fixed truncation range start values advertised in
the "capabilities" action response.

Should perhaps say
or has a value
outside any fixed truncation range values advertised in
the "capabilities" action response.

This provides an error for the first element that is incorrect, while
invalid-end would be flagged where invalid-start is also the case with a
date greater than the capability end date.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 18 Nov 2014 09:57:53 -0500

Hi Lester,

> the "capabilities" action response.

Yup - you're right. Wording fixed in my working copy.

-- 
Cyrus Daboo

---

From: Tim Parenti <[email-masked]>
Date: Thu, 20 Nov 2014 00:09:10 -0500

I think it's good that the §3.8
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-3.8>¶3
mandates that the server advertise the range it can supply, but per my
comments at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00909.html, I think
it's lopsided that ¶5 specifies how truncation bounds should be returned in
VTIMEZONE responses, while nothing currently specifies how they should be
returned in JSON responses.  I'm not sure whether this is a better fit for
§3.8 <http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-3.8>
 or §5.4
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03#section-5.4>.

Part of #21 <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/21>, which
was actually several issues combined, tried to suggest how this should be
returned, but that discussion was overshadowed by the bigger sub-issues on
that ticket.  Revised for the latest draft (03), and based on Ken's latest
implementation, for
https://cyrus-test.andrew.cmu.edu/tzdist/observances/America/New_York?start=2014-07-01T00:00:00Z&end=2015-07-01T00:00:00Z,
this would look something like:

{
  "dtstamp": "2014-10-03T14:56:59Z",
  "tzid": "America/New_York",
  "observances": [
    {
      "name": "EDT",
      "onset": "2014-07-01T00:00:00Z",
      "utc-offset-from": -14400,
      "utc-offset-to": -14400
    },
    {
      "name": "EST",
      "onset": "2014-11-02T06:00:00Z",
      "utc-offset-from": -14400,
      "utc-offset-to": -18000
    },
    {
      "name": "EDT",
      "onset": "2015-03-08T07:00:00Z",
      "utc-offset-from": -18000,
      "utc-offset-to": -14400
    }
  ]*,
  "observance-bounds": [
    "2014-07-01T00:00:00Z",
    "2015-07-01T00:00:00Z"
  ]*
}

I don't really like the name "observance-bounds" but am struggling to come
up with anything better right now.

--
Tim Parenti

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 20 Nov 2014 09:44:17 -0500

Hi Tim,

> up with anything better right now.

Actually I changed the expand action to require the client to send both a 
start and end range - that means the client has to ensure that the 
start/end are within a valid truncation range, if not, the server fails the 
request. With that behavior, there will never be any truncation of the 
expand action results and thus it avoids the need to add new items into the 
response to indicate that. I took this approach because it seemed to me 
that clients are going to have to be fully aware of truncation any way - 
either they make sure the start/end fits within the advertised truncation 
range or they deal with a response that indicates truncation occurred. I 
decided the former was the simpler approach.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Thu, 20 Nov 2014 18:41:10 +0000

On 20/11/14 14:44, Cyrus Daboo wrote:
> Actually I changed the expand action to require the client to send both
> a start and end range - that means the client has to ensure that the
> start/end are within a valid truncation range, if not, the server fails
> the request. With that behavior, there will never be any truncation of
> the expand action results and thus it avoids the need to add new items
> into the response to indicate that. I took this approach because it
> seemed to me that clients are going to have to be fully aware of
> truncation any way - either they make sure the start/end fits within the
> advertised truncation range or they deal with a response that indicates
> truncation occurred. I decided the former was the simpler approach.

This does still leave the problem that some rule sets may have a
truncated range due to the rule rather than the selected truncation
range? If a rule set can't be safely expanded to cover the full
truncation range should the capable truncation range be clipped for all
rules, or SHOULD the process allow that where a shorter period is all
that is available then that is returned?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Nov 2014 19:44:25 +0100

No hats..

Whichever is fine with me, but either way should be documented.

Eliot

---

From: Tim Parenti <[email-masked]>
Date: Fri, 21 Nov 2014 00:30:02 -0500

On 20 November 2014 13:41, Lester Caine <[email-masked]> wrote:

> range?

Exactly.  It simply doesn't make sense to me to have TZ-UNTIL for one
response type, but no equivalent parameter for the other.

I suppose the starting bound is implicit in both the request and the
response (by virtue of how the first observance is returned).  Maybe just
call it "tz-until" and include it in the same situations we would include
it for a VTIMEZONE response?  (That is, whenever the end is truncated
either by request or by rule.)

On 20 November 2014 13:44, Eliot Lear <[email-masked]> wrote:

> either way should be documented.

Of course.

--
Tim Parenti