Subject: [Ietf-calsify] rrule in timezone components

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Tue Mar 6 08:58:13 2007

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
      MUST represent a unique time zone definition.  This is necessary
      for some classes of events, such as airline flights, that start in
      one time zone and end in another.

The above seems a bit silly.  Planes travel WRT to UTC, or perhaps best take 
off WRT to local time.  If the US changes it's TZ definition does that mean 
the flight gets longer by 1 hour?  Probably more relevant to say:

      MUST represent a unique time zone definition.  This is necessary
-      for some classes of events, such as airline flights, that start in
-      one time zone and end in another.
+      for some classes of events, such as a tour which has events in
+      more than one timezone.

But what I really came here to say was, consider:

        BEGIN:VTIMEZONE
        TZID:Fictitious--with ridiculous rrule
        BEGIN:STANDARD
        DTSTART:19671029T020000
        RRULE:FREQ=HOURLY;INTERVAL=2
        TZOFFSETFROM:-0400
        TZOFFSETTO:-0500
        END:STANDARD
        BEGIN:DAYLIGHT
        etc
        END:DAYLIGHT
        END:VTIMEZONE

We are also told that DTSTART MUST be a local time. If DTSTART is a local 
time, then normally to decode an hourly/minutely/secondly recurring rules, 
we need to know what to do about timezone shifts.  But that's exactly what 
we are defining.  Not only does this seem messy to me, but I also think 
mallicious recurrence rules warrant mention in the security section as they 
could add considerable cpu/memory burdens on some implementations.

Surely we should really use the DATE from DTSTART and the RRULE to establing 
the DATE of the recurrence, with the intention being that there be only one 
date in the recurrence set per year, and then use the TIME from the 
DTSTART-OFFSETFROM to build the DATE-TIME of the point in UTC at which we 
apply the new offset.  I'd like to suggest that we add this:

      The "RRULE" property defines the recurrence rule for the onset of
      the observance defined by this time zone sub-component.  Some
      specific requirements for the usage of "RRULE" for this purpose
      include:

      *  If observance is known to have an effective end date, the
         "UNTIL" recurrence rule parameter MUST be used to specify the
         last valid onset of this observance (i.e., the UNTIL date-time
         will be equal to the last instance generated by the recurrence
         pattern).  It MUST be specified in UTC time.

      *  The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
         when generating the onset date-time values (instances) from the
         "RRULE".

+      *  If present, the "RRULE" MUST have a "FREQ" of "YEARLY" and MUST
+          NOT use "BYHOUR", "BYMINUTE", "BYSECOND".  The "RRULE"
+          SHOULD define a recurrence set that includes a single instance 
per year.
+          Where the "RRULE" specifies more than one instance per year, 
implementations
+          SHOULD ignore all but the first instance.

Nigel

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Mar 6 09:46:36 2007

Hi Nigel,

--On March 6, 2007 4:57:01 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> The above seems a bit silly.  Planes travel WRT to UTC, or perhaps best
> take off WRT to local time.  If the US changes it's TZ definition does
> that mean the flight gets longer by 1 hour?  Probably more relevant to
> say:
>

I believe the original intent of that was to describe the case of an event 
where the DTSTART and DTEND used different TZIDs. A single event 
representing travel between locations with different timezones is one 
example (though we can debate about the utility of using DTEND+different 
TZID, vs DURATION). Your example of different events in different timezones 
is also valid.

I actually suggest removing the "This is necessary..." sentence altogether, 
as we state further down:

> An individual "VTIMEZONE" calendar component MUST be specified for
>       each unique "TZID" parameter value specified in the iCalendar
>       object.

Which I think adequately describes the constraint.

-- 
Cyrus Daboo

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Tue Mar 6 10:36:16 2007

> TZID, vs DURATION). Your example of different events in different 
> timezones is also valid.
>
> I actually suggest removing the "This is necessary..." sentence 
> altogether, as we state further down:

I'd be happy with that too.  :o)

Nigel

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Tue Mar 6 11:35:51 2007

>      one time zone and end in another.

Speaking from a position of semi-safety, and knowing that I can't be 
burned at the stake for heresy in this may I ask a series of simple 
questions?

I know these questions are as silly as questioning the fact that the sun 
revolves around the earth, but please, bear with me.

1)   In order to write a really accurate VTIMEZONE record you need a 
source of information. The only really generic, solid source of this 
information that I'm aware of is the Olson Time Zone Database.

2)   The VTIMEZONE is in essence a series of rules, describing the 
shifts of the time zone. IOW, it's perhaps a slightly more structured 
rendition of the data in the Olson time zone database.

3)   Some programming languages (Like Java in particular), and most 
operating systems now use the Olson Time Zone DB as their reference 
source. Java can convert time from one TZ to another TZ, with no effort.

4)   VTIMEZONE is a unique thing, tied specifically to iCal, and not 
used by any other standard.

Given all of these things, why would it not make sense to:

a)   Deprecate VTIMEZONE and say that all VEVENT time zone references 
must reference an Olson TZ Definition. After all, to write a really 
decent VTIMEZONE entry you need to have this present anyway and be able 
to parse it.

b)   Create a standardized C/ (or other programming language) that can 
read the Olson TZ database, and perform the conversion.

The benefits of this would be that developers could use a standard set 
of library functions for time zone conversions rather than creating a 
custom implementation. This library could be shared with other 
applications and would achieve maturity and correctness very quickly.

So, my heretical question is why are you hanging on to VTIMEZONE 
records? They're archaic and honestly there are just better things out 
there now.

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Mar 6 11:51:31 2007

Hi George,

> read the Olson TZ database, and perform the conversion.

Like:

<http://dialspace.dial.pipex.com/prod/dialspace/town/pipexdsl/s/asbm26/vzic/>

which I believe a lot of people already use? I think there are some other 
tools that will do that too. A good reference is:

<http://www.twinsun.com/tz/tz-link.htm>

There has also been discussion of having a formal timezone registry with 
IANA that could use Olson to generate a set of VTIMEZONE definitions that 
everyone could then use. But that is out of scope for the calsify effort, 
as is actually deprecating VTIMEZONE altogether (which would have a major 
impact in terms of backwards compatibility).

-- 
Cyrus Daboo

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Tue Mar 6 15:52:15 2007

> impact in terms of backwards compatibility).

I agree with George.  But I suspected it would be too big a change to deprecate VTIMEZONE at this time hence chose a different tack.  

I consider my suggestion a lot less jarring, and still in the remit of calsify?  It's the specifying that FREQ must = YEARLY that I think has the biggest gains.

Nigel

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Tue Mar 6 23:18:40 2007

There's a step short of deprecating VTIMEZONE that would help weather
events like the upcoming US timezone changes.

>From 4.2.19
   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
   prefix, indicates that this TZID represents a unique ID in a globally
   defined time zone registry (when such registry is defined).

The spec could recommend an external TZID format like
//Olson/<olson-id> which would help ical generators pick names that
can be easily interpreted by others and explicitly permit calendaring
systems that recognize that format to substitute their own definition.

It would also make ical better as a persistence format.   You can
include you're VTIMEZONE definition, but if the TZID is
//Olson/America/Los_Angeles then a calendaring system that knows it
has a more up-to-date definition of Los Angeles time could feel free
to substitute it.

mike

On 06/03/07, Nigel Swinson <[email-masked]> wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Mar 7 06:27:07 2007

Putting aside the fact that we are no longer entertaining changes beyond 
the scope of changes made in response to closing open issues, I can 
think of one reason why the Olson database itself is insufficient: it's 
not versioned.  You can't simply refer to America/Los_Angeles and 
understand what people meant.  Was it the old definition that had DST 
starting a few weeks from now or the new version where it starts in a 
few days?

As others have mentioned, we have discussed in the past sticking all of 
this information in the DNS and elsewhere to make it interactively 
retrievable.  One of the other nice things about the way things are is 
that iCalendar objects are intended to be self-consistent requiring no 
additional lookups.  This has some drawbacks, obviously, one of which is 
that it makes for additional hair in server implementations.

These problems are not unsolvable, but will have to wait for another day.

Eliot

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Mar 7 07:46:59 2007

> the scope of changes made in response to closing open issues, 

So are we at least registering these ideas for discussion/action later rather than ignoring them as not on the "blessed list of open issues"?  Again I can appreciate that dropping VTIMEZONE is a fairly major change, but surely restricting FREQ to yearly isn't so controversial we don't have the bandwidth to agree on that now?

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Mar 7 07:52:09 2007

Hi Eliot,

--On March 7, 2007 3:26:04 PM +0100 Eliot Lear <[email-masked]> wrote:

> the scope of changes made in response to closing open issues, I can think
> of one reason why the Olson database itself is insufficient: it's not
> versioned.  You can't simply refer to America/Los_Angeles and understand
> what people meant.  Was it the old definition that had DST starting a few
> weeks from now or the new version where it starts in a few days?

Strictly speaking its not Olson that is unversioned, but rather the common 
VTIMEZONE derivations from Olson (remember Olson itself is not an iCalendar 
format - it has to be converted). The Olson db itself does have regular 
updates tagged by a "version" string - e.g., the current version is 
tzdata2007c, the previous one is tzdata2007b, etc.

The vzic conversion tool does allow you to specify different prefixes to 
timezone names. So with that, someone who cared about versioning could 
easily generate timezones with ids like /tzdata2007c/America/New_York etc. 
The trouble is it is up to each individual or organization that uses 
converted Olson VTIMEZONEs to do that themselves, and each could choose to 
use their own format for the ids etc.

> These problems are not unsolvable, but will have to wait for another day.

Agreed - this is a post-calsify effort. But it is one that is important, I 
believe.

-- 
Cyrus Daboo

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Mar 7 08:00:27 2007

Hi Nigel,

--On March 7, 2007 3:47:04 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> So are we at least registering these ideas for discussion/action later
> rather than ignoring them as not on the "blessed list of open issues"?
> Again I can appreciate that dropping VTIMEZONE is a fairly major change,
> but surely restricting FREQ to yearly isn't so controversial we don't
> have the bandwidth to agree on that now?

This seems like something of an arbitrary restriction just for VTIMEZONE. 
Given that you have to support the full gamut of RRULE in VEVENT, VTODO 
etc, why does it matter if an RRULE in a VTIMEZONE is

RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

as opposed to:

RRULE:FREQ=MONTHLY;BYMONTH=3;BYDAY=2SU

They both generate the same set. Why add more complexity by saying RRULE in 
VTIMEZONE is special and has extra restrictions that RRULE elsewhere does 
not?

Of course it is true that wherever possible is probably more efficient from 
a computational standpoint to always use the highest FREQ value 
representation possible as they will result in the need to generate fewer 
"cycles" (* - see below) to calculate the recurrence set. Probably the same 
thing as saying its better to use a FREQ/BYxxx rule where the BYxxx rules 
"expand" the set of instances within one cycle, as opposed to a FREQ/BYxxx 
rule where the BYxxx rules remove entire cycles.

* - I define a "cycle" as one iteration over the FREQ value.

-- 
Cyrus Daboo

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Mar 7 08:38:54 2007

> VTIMEZONE is special and has extra restrictions that RRULE elsewhere does 

Primarily for reasons of security and resuource usage but also to *reduce* implementational complexity.  RRules in timezones clearly must relate to annual events by the very definition of DST, and all the examples in the spec do so just now, so it seems like sensible advice to promote ineteroperability and protect installations.

Besides, you imply some neat recurrence engine that you can call arbitrarily from event, todo, timezone.  I don't think you can do that correctly, as we have to treat VTIMEZONE specially anyway:

An event can have a recurrence rule and a date-time dtstart.  This means you (potentially) need to understand the timezone in order to expand the recurring rule.  But to understand the timezone, you may need to expand a recurrence rule which comes with another date-time dtstart.   This is a cyclic dependancy which was complex to fix.  

I found you end up with three recurrence engines, one that operates on dtstart of type date, one on UTC and one on LocalTime.  The timezone recurrence engine uses the UTC recurrence engine, and thus doesn't need to adjust for a timezone, despite the fact that the standard goes to great pains to tell me that dtstart is a local time, not in UTC.  I couldn't see how I could consider that as a local time as how then could I know how to adjust for DST when that's exactly what I was trying to define?  So I combine dtstart and offsetfrom and use the UTC recurrence engine.  The event can then use the LocalTime recurrence engine to expand it's rrule, where a localtime can combine the timezone and the datetime and thus break the cyclic dependancy.

> rule where the BYxxx rules remove entire cycles.

So I am wanting to be able to legally object to timezone definitions that could have been more efficiently expressed as freq=yearly, and wanting to discourage future implementors from creating vtimezones that do otherwise.

Nigel

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Mar 7 09:27:02 2007

Hi Mike,

> systems that recognize that format to substitute their own definition.

Yup - that is the concept of a standard registry with the option of a 
timezone service that can deliver updated definitions to those who are 
interested. Calconnect did write a document with recommendations for such a 
service:

<http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf>

> has a more up-to-date definition of Los Angeles time could feel free

Actually, automatically updating timezones is not always appropriate. One 
of the big problems vendors have had with the upcoming EDST change is 
figuring out which events really should be upgraded. In practice you cannot 
automatically do that because sometimes users create events using their own 
local timezone, but the actual event is "anchored" in someone else's 
timezone.

e.g. someone in the UK calls up and tells me a future meeting is 15:00 GMT, 
which is 10:00 my time, so I go and enter it as 10:00 EST on my calendar. 
But then the DST rule changes for that period. If the VTIMEZONE were 
automatically updated, then my meeting time would be off by an hour.

That is why most calendar product vendors have had to tell their users that 
they need to double-check all meetings during the EDST change periods to 
verify they really are when they are supposed to be. This is obviously not 
an ideal situation. It will be interesting to see how many people miss 
meetings next Monday!

Speaking of which, which timezone are our jabber sessions on Thursday 
"anchored" in? The last iCal that Elliot sent out used an updated 
TZID:America/Los_Angeles except this Thursday is the last in the recurrence 
set - so I guess we get to fight over who absorbs the hour offset for the 
next few weeks where DSTs are not in sync across continents!

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Mar 7 12:21:40 2007

Cyrus Daboo wrote:
> TZID:America/Los_Angeles except this Thursday is the last in the 
> recurrence set - so I guess we get to fight over who absorbs the hour 
> offset for the next few weeks where DSTs are not in sync across 
> continents!
>

Conveniently here comes the IETF face to face meeting ;-)