Subject: [Ietf-calsify] Time Zone Rule Changeover

From: caleb at everyone.net (Caleb Richardson)
Date: Thu Jun 22 18:42:01 2006

This question concerns the switch from standard time to daylight savings 
time in the United States that will occur on March 11, 2007.

 From what I understand most versions of Outlook (and some other CUAs) 
can only process VTIMEZONE observances with at most one RRULE property. 
This has led most Olson database converters to discard all historical 
data and only use the most recent recurrence rule for each observance 
(if there are any).

The switchover on March 11, 2007 will be the first that uses a new time 
zone recurrence rule standardized by the Energy Policy Act of 2005. The 
previous rule would have required a switchover on April 1, 2007.

Which recurrence rule should I use?

If I use the old rule then recurring events that are still happening 
next spring will be 1 hour off for that window and for a similar window 
every year.

If I use the new rule then my events will be 1 hour off during a similar 
window this fall.

Has anyone come up with a solution to this problem? I realize that many 
CUAs (including mine) will look at the TZID parameter and try to use 
their own strict time zone definitions before parsing the included one, 
but I feel that this is a serious problem regardless.

Thanks,

Caleb Richardson

This VTIMEZONE definition uses the new recurrence rule:

BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE

This VTIMEZONE definition uses the old recurrence rule.

BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700405T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Jun 28 02:56:26 2006

[Chair hat off...]

Caleb,

You'll notice that nobody has answered your question, and I will not
either.  When an implementation fails to conform a standard it is either
because the standard is difficult to implement or because the
implementor just didn't do a good enough job.  Now is the time to decide
which is true.  There is an issue tracker and an upcoming meeting of the
Calsify working group.  Now is the time to raise and discuss these sorts
of questions.

Let me say that anyone who wants a change in the status quo should in
general send text.  Lacking that it's very difficult to argue pros and
cons on each side.

Eliot

Caleb Richardson wrote:
> This question concerns the switch from standard time to daylight
> savings time in the United States that will occur on March 11, 2007.
>
> can only process VTIMEZONE observances with at most one RRULE
> property. This has led most Olson database converters to discard all
> historical data and only use the most recent recurrence rule for each
> observance (if there are any).
>
> The switchover on March 11, 2007 will be the first that uses a new
> time zone recurrence rule standardized by the Energy Policy Act of
> 2005. The previous rule would have required a switchover on April 1,
> 2007.
>
> next spring will be 1 hour off for that window and for a similar
> window every year.
>
> If I use the new rule then my events will be 1 hour off during a
> similar window this fall.
>
> Has anyone come up with a solution to this problem? I realize that
> many CUAs (including mine) will look at the TZID parameter and try to
> use their own strict time zone definitions before parsing the included
> one, but I feel that this is a serious problem regardless.
>
> Thanks,
>
> Caleb Richardson
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>