Subject: [calsify] VTIMEZONES with onset times in the future of appointments

From: Gren Elliot <[email-masked]>
Date: Fri, 26 Feb 2010 14:06:33 +0000

Hi,

I'm starting to see ICAL appearing in the wild from a well known mobile 
phone provider's devices with VEVENT dates referencing a VTIMEZONE 
component whose rules' onset times are in the future of the actual 
appointment.  Any views on how these should be treated?  The libical 
library we use assumes (not unreasonably IMHO) that such times are UTC - 
which is clearly at odds with the actual intent.

For example, the following contains a VTIMEZONE with only 2 rules that 
first apply from 14th March (DST) or 17th Nov (Standard) this year, but 
the appointment is on 17th February this year...

...
BEGIN:VTIMEZONE
TZID:US/Central
BEGIN:DAYLIGHT
DTSTART:20100314T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:CDT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20101107T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:CST
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
...
DTSTART;TZID=US/Central:20100217T170000
DTEND;TZID=US/Central:20100217T180000
...

Regards,
Gren.

-- 
Gren Elliot
Senior Software Engineer
*Scalix*
[email-masked]
Tel: +44 1344 381812
www.scalix.com

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Feb 2010 10:05:04 -0500

Hi Gren,

> the appointment is on 17th February this year...

If the timezone id is "well known" you could simply map the client's 
timezone to one your server has stashed (and which is complete) and just 
substitute that. Our server does that - we use the Olson db and parse that 
on startup to cache timezone ids. Then whenever a new id is seen the 
calendar library loads the timezone definition from our cache rather than 
use the one in the data provided. Of course this is risky in that it 
assumes the same timezone id is really being used the same way by both 
client and server - but at this point I think we have to reasonably make 
that assumption.

One day we will have a standard timezone registry so there would be a 
guarantee that ids always represent the same set of timezone rules. This is 
a perfect example of why such a registry is needed!

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Feb 2010 10:05:04 -0500

Hi Gren,

-- 
Cyrus Daboo

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: Gren Elliot <[email-masked]>
Date: Fri, 26 Feb 2010 15:53:41 +0000

On 26/02/2010 15:14, Rick DeNatale wrote:
> As I understand it, in the case of an event time prior to the event
> time with a timezone, you should use the UTC offset specified in the
> TZOFFSETFROM property of the earliest DAYLIGHT or STANDARD period of
> that time zone, which would be the DAYLIGHT period starting at
> 20100314T020000, so the offset would be -0600,
>
> Note that each DAYLIGHT/STANDARD period carries not only the offset to
> be applied during that period, but also the offset applied for the
> previous period.
>
> This allows for dealing with times before a given timezone existed, or
> more to the point before daylight savings time was introduced to a
> given timezone.
>    

Good point - I hadn't thought of that aspect.  In which case the problem 
isn't as bad as I had thought it was.
Cyrus's suggestion on using the system timezone definitions in 
preference also has a lot of merits.
I'll probably end up with fixes based on some mix of the 2 ideas (as not 
all TZIDs may be known on the system).

Thanks to you both,

Regards,
Gren.

---

From: Gren Elliot <[email-masked]>
Date: Fri, 26 Feb 2010 15:53:41 +0000

Thanks to you both,

Regards,
Gren.