Subject: [Ietf-calsify] Time Zones

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Aug 18 08:25:08 2004

Hmmm.  I'd hate to complicate recurrence patterns in all this.  Perhaps
time zones aren't so bad, but do we really need custom ones?

cam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Wednesday, August 18, 2004 8:01 AM
To: Dan Winship
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones

On Aug 18, 2004, at 16:50, Dan Winship wrote:
> On Wed, 2004-08-18 at 14:52 +0200, Helge Hess wrote:
>> The one place where timezones might be required are recurring events,
> Exactly so. We can't drop time zones unless we're dropping unbounded 
> recurrences as well. (Which I don't think we should.)

OK.

What do you think about attaching the timezone rule directly to the
cyclic event? The dates of the event could still be required to be
specified in UTC and the rule would just need to specify the ranges
where this the cycle is different?
This might be easier to handle by both, clients and servers?

Greets,
   Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Aug 18 08:34:44 2004

> time zones aren't so bad, but do we really need custom ones?

What do you mean by "custom ones"?

There are three "levels" of timezone support:
a) just UTC (Zulu)
b) only fix offsets from UTC (GMT+0400) [provides no advantage]
c) political timezones (either by name or as a ruleset)

What I'm suggesting is to remove timezones and instead just add the DST 
exception intended by the event creator. The client can calculate the 
UTC relative DST range based on the political tz information it needs 
to have anyway. The transport/store doesn't need to bother anymore.
Drawback: if a political timezone changes, the cycle event is broken 
(but the same is true for rules encoded in the iCal file itself).

This approach actually doesn't complicate recurrence patterns, it makes 
them easier because the pattern processor doesn't need to consider 
timezones (and it makes all the non-cyclic stuff much easier).

IMHO its also more semantically correct, because the recurrence 
timezone is a property of the cycle calculation and not a property of 
the start/enddate of the cycle. (what happens today with clients if a 
cycle vevent specifies a different timezone for startdate and enddate? 
;-)

Greets,
   Helge