Subject: [Tzdist] draft-douglass-timezone-service-11: Include tzid in response?

From: Mike Douglass <[email-masked]>
Date: Wed, 20 Aug 2014 09:42:45 -0400

I've been taking another look at action=expand and the response. 
Currently we have it like this

  {
     "dtstamp": "2009-10-11T09:32:11Z",
     "observances": [
       {
         "name": "Standard",
         "onset": "2008-01-01T00:00:00",
         "utc-offset-from": -18000,
...

I think it would be helpful to have the tzid in the response making the 
data completely self describing.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 20 Aug 2014 10:04:52 -0400

Hi Mike,

If we're talking about adding it before the observances array, I 
wouldn't have a problem with that.

On 08/20/2014 09:42 AM, Mike Douglass wrote:
> I think it would be helpful to have the tzid in the response making 
> the data completely self describing.
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 15:52:10 +0100

> data completely self describing.

I've just got to this area and I assume since there is no provision to
identify any of the repetition elements from tz that the observances
array is anticipated to have entries for every year? I was expecting to
see something like the 'lastSun' and similar tags so that we do not have
an open ended list of events? I think 'oname' needs expanding to allow
for LMT as a starting point, and then the start of DST events would
simply be tagged as start and stop observances.

I'm getting the feeling that this draft still has a lot of holes to be
plugged before it CAN be adopted? I'm not sure all of the requirements
or the tzdist system have even been documented yet?

-- 
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: Wed, 20 Aug 2014 11:08:32 -0400

Hi Lester,

> simply be tagged as start and stop observances.

The whole purpose of the expand action is to provide the actual list of 
observances - not the "pattern". The idea is that lightweight clients 
probably only care about observances over a very specific (small) range of 
time (e.g., a web-calendar client displaying this months events only cares 
about local time offsets within that period). Such clients would rather 
have that small list compared to being given a full iCalendar VTIMEZONE 
object with potentially complex recurrence rules to expand.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 17:22:57 +0100

On 20/08/14 16:08, Cyrus Daboo wrote:
> probably only care about observances over a very specific (small) range
> of time (e.g., a web-calendar client displaying this months events only
> cares about local time offsets within that period). Such clients would
> rather have that small list compared to being given a full iCalendar
> VTIMEZONE object with potentially complex recurrence rules to expand.

Then what command should I be using to replicate the 'pattern' to a
secondary server so it can generate the truncated views? And how is the
end point of a truncated view defined?

---

From: Ken Murchison <[email-masked]>
Date: Wed, 20 Aug 2014 12:36:52 -0400

Hi Lester,

> end point of a truncated view defined?

A secondary server would use the 'get' action to fetch the entire 
timezone definition provided by the primary server.  The secondary would 
then use that definition to generate any occurrences requested by a 
client using the 'expand' action'  The client can request an explicit 
range of occurrences to expand with the 'start' and 'end' query parameters.

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 17:37:35 +0100

On 20/08/14 17:22, Lester Caine wrote:
>> Such clients would

OK - I've found the VTIMEZONE element now ... I'd not appreciated that
this was built in to the proposal as I was assuming we were simply
producing that if required. I've been working on making the history of
changes in the tz database available so one can see when a normalized
UTC timestamp will now produce a different result. While calendering
meetings in the next few months is a short term window, my own records
have minutes of meetings normalised to UTC going back in time and it is
maintaining accuracy in the past history which prompted my own need to
understand WHY historic records were changing. A tz server needs to be
able to return accurate current offsets, but also recreate 'light'
results that match what it produced when those were first served up.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Aug 2014 12:45:51 -0400

Hi Lester,

> end point of a truncated view defined?

The "get" action 
(<http://tools.ietf.org/html/draft-douglass-timezone-service-11#section-6.3>) 
returns the full time zone definition with rules, as per the chosen media 
type (MIME content-type) - truncation can optionally be applied. In the 
case of iCalendar, the returned time zone data would include the rules, not 
the expanded observances.

If client requests truncation, then the server truncates the data to remove 
observances, and adjust rules, earlier than the truncation year. In the 
last paragraph of 
<http://tools.ietf.org/html/draft-douglass-timezone-service-11#section-3.4> 
we describe how with iCalendar an additional observance component is added 
at the point of truncation. Since the client was the one requesting the 
truncation, it can interpret that as needed.

Below is what an iCalendar VTIMEZONE looks like for America/New_York 
(un-truncated, derived from Olson TZDB):

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//calendarserver.org//Zonal//EN
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:STANDARD
DTSTART:18831118T120358
RDATE:18831118T120358
TZNAME:EST
TZOFFSETFROM:-045602
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19180331T020000
RRULE:FREQ=YEARLY;UNTIL=19190330T070000Z;BYDAY=-1SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19181027T020000
RRULE:FREQ=YEARLY;UNTIL=19191026T060000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:STANDARD
DTSTART:19200101T000000
RDATE:19200101T000000
RDATE:19420101T000000
RDATE:19460101T000000
RDATE:19670101T000000
TZNAME:EST
TZOFFSETFROM:-0500
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19200328T020000
RDATE:19200328T020000
RDATE:19740106T020000
RDATE:19750223T020000
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19201031T020000
RDATE:19201031T020000
RDATE:19450930T020000
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19210424T020000
RRULE:FREQ=YEARLY;UNTIL=19410427T070000Z;BYDAY=-1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19210925T020000
RRULE:FREQ=YEARLY;UNTIL=19410928T060000Z;BYDAY=-1SU;BYMONTH=9
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19420209T020000
RDATE:19420209T020000
TZNAME:EWT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19450814T190000
RDATE:19450814T190000
TZNAME:EPT
TZOFFSETFROM:-0400
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19460428T020000
RRULE:FREQ=YEARLY;UNTIL=19660424T070000Z;BYDAY=-1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19460929T020000
RRULE:FREQ=YEARLY;UNTIL=19540926T060000Z;BYDAY=-1SU;BYMONTH=9
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:STANDARD
DTSTART:19551030T020000
RRULE:FREQ=YEARLY;UNTIL=19661030T060000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19670430T020000
RRULE:FREQ=YEARLY;UNTIL=19730429T070000Z;BYDAY=-1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;UNTIL=20061029T060000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19760425T020000
RRULE:FREQ=YEARLY;UNTIL=19860427T070000Z;BYDAY=-1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;UNTIL=20060402T070000Z;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 19:06:38 +0100

> (un-truncated, derived from Olson TZDB):

Soory to be a pain here - I've never bothered with iCalendar so I will
have to read up on that as well, but the bit I'm just trying to nail
down is the timestamping of the version of VTIMEZONE being served up.
expand has a "dtstamp" for the package being served up, so if the list
of timezones was downloaded earlier and an update has occurred in the
server then the package of data has the right stamp, but the get request
is reliant on the "dtstamp" provided with the earlier list command?

Does VTIMEZONE have a tag to identify it's version? There was not one on
the example you provided so how does one know if it's changed since it
was last used?

Seems strange having different packet formats for different commands ...

---

From: Ken Murchison <[email-masked]>
Date: Wed, 20 Aug 2014 14:12:01 -0400

Hi Lester,

> is reliant on the "dtstamp" provided with the earlier list command?

Yes.

> the example you provided so how does one know if it's changed since it

In my implementation I include a LAST-MODIFIED property in the VTIMEZONE 
which is the same as that in the list output.