Subject: [Ietf-calsify] Future-proofing VTIMEZONE

From: Andrew Daviel <[email-masked]>
Date: Mon, 3 Dec 2007 16:01:28 -0800 (PST)

Apologies if this has been hammered to death already... I just joined, 
and grepping archives for an unknown keyword is not always fruitful

I've been trying to write a CalDAV server for Mozilla clients (OK, 
according to the RFC it's not one because it doesn't implement all the 
mandatory stuff..).

I notice that events in 2445 are tagged with a TZID (I was a bit slow 
realizing why; why not just translate everything to UTC).

I presume the intention is that repeating events (10:00 every Wednesday) 
should be maintained in correct local time, regardless of DST changes. 
But as I understand it, VTIMEZONE (at least in the Mozilla clients) 
contains only the DST rules currently in effect (I admit, predicting 
future rules is impossible and though Dr. Who might schedule meetings in 
the past, most people don't). So if the rules change, pre-existing 
repeating events will be wrong. (In Canada/USA, we just went through an 
annoying and pointless (from an IT point of view) rule change, and the US 
law leaves open the possibility of putting it all back how it was if 
no-one saves energy. And Australia as I recall made a special change for 
the 2000 Olymics. So this is not an unlikely scenario.)

So VTIMEZONE doesn't really work. It would seem more useful to use some 
defined list of timezones, e.g. Pozix or O/S system rules which hopefully 
get updated, and then repeating events would be future-proofed against 
most rule changes, not just for known DST transistions. (Locations might 
still hop from one zone to another, e.g. a certain locality suddenly 
decides to opt out of its parent zone's DST)

Perhaps the optional TZURL element is a solution to this.
if so, how many people are actually implementing it ?

-- 
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376  (Pacific Time)
Network Security Manager
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Dave Thewlis <[email-masked]>
Date: Mon, 03 Dec 2007 19:50:19 -0800

Andrew,

You might take a look at

http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf

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

http://www.calconnect.org/tc-timezone.shtml

Cheers,

Dave Thewlis

Andrew Daviel wrote:
> I presume the intention is that repeating events (10:00 every 
> Wednesday) should be maintained in correct local time, regardless of 
> DST changes. But as I understand it, VTIMEZONE (at least in the 
> Mozilla clients) contains only the DST rules currently in effect (I 
> admit, predicting future rules is impossible and though Dr. Who might 
> schedule meetings in the past, most people don't). So if the rules 
> change, pre-existing repeating events will be wrong. (In Canada/USA, 
> we just went through an annoying and pointless (from an IT point of 
> view) rule change, and the US law leaves open the possibility of 
> putting it all back how it was if no-one saves energy. And Australia 
> as I recall made a special change for the 2000 Olymics. So this is not 
> an unlikely scenario.)
>
> So VTIMEZONE doesn't really work. It would seem more useful to use 
> some defined list of timezones, e.g. Pozix or O/S system rules which 
> hopefully get updated, and then repeating events would be 
> future-proofed against most rule changes, not just for known DST 
> transistions. (Locations might still hop from one zone to another, 
> e.g. a certain locality suddenly decides to opt out of its parent 
> zone's DST)
>

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 04 Dec 2007 10:54:36 -0800

Hi Andrew,

> decides to opt out of its parent zone's DST)

Mostly what you are seeing is a client implementation detail. Its true that 
some clients truncate the full timezone data to just that portion needed to 
cover the events they are attached too. Whilst that is OK for those events 
as they stand at that time, as you note, it breaks if you try to change any 
of those events to a date outside of the truncated timezone.

Other clients do send a complete representation of the timezone with the 
event data that does cover the future. However, changes to dst rules made 
in the future will cause a similar problem.

To help resolve these issues the Calendaring and Scheduling Consortium 
(Calconnect) is working on the concept of a standard timezone registry and 
service that could be used to alleviate many of the current problems. The 
goals for this are:

1) Provide a standard namespace for timezones names (via an IANA registry). 
This would allow "formal" standardization of e.g. Olson TZ names, and names 
from other sources.

2) Define a protocol whereby a client can retrieve timezone data given just 
the name of a timezone. i.e. timezones can be passed "by reference" instead 
of "by value" in iCalendar data.

3) Provide a simple update mechanism by which clients can ensure their 
timezone data caches are up to date with the latest timezone information.

Calconnect is still working on the preliminary requirements for this 
effort. The goal is to bring all this work to the IETF for formal 
specifications in an appropriate venue.

Note that right now the focus of the Calsify WG is to revise the current 
specs, so we are all focussing on completing that work right now.

-- 
Cyrus Daboo