Subject: Re: Timezone TZID clashes

From: [email-masked]
Date: Mon, 19 Mar 2001 16:37:12 -0500

Damon replied with:
>If the app loads/receives an iCalendar file with, for example, a 
"Europe/London"
>VTIMEZONE calendar component, and the user then creates another time with 
the
>timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE
>components to place in the iCalendar file.

Ok, Im probably too defocused on iCal right now but I do not quite grok 
the scenario fully.  I get an invite from Damon w/a VTIMEZONE in it for 
"Europe/London".  My CUA will crack open the incoming REQUEST and 
VTIMEZONE and converts it (at least internally) to, say, some UTC format 
relative to my default/configured TZ.  How then do I create "another time" 
(a different entry or REQUEST??) for "Europe/London" that utilizies a 
different definition of that TZ?  The new entry/event would utilize _my_ 
definition of "Europe/London" and when I send out REQUESTs it would 
contain _my_ VTIMEZONE for "Europe/London", not the one I received from 
Damon.

Ahh, is it the case that your CUA uses iCalendar as the native file format 
and it just stores the raw streams together in some indexed way???  I 
would stipulate that the CUA that does this needs to 'localize' the entry 
if it can to avoid problems like you are mulling over.  When I say 
'localize' I mean TZ match and shift to its own definitions that match the 
ones coming in and use the matched defintions and change the date/time 
values accordingly before saving to a file.  Matching is not always a 
trivial task (ie: RRULE on the REQUEST but RDATEs in the CUA for the same 
TZ definition) but its not as hard as some of our other workflow cases 
(like Delegation chains)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Damon Chaplin <[email-masked]>
Date: Tue, 20 Mar 2001 14:57:39 +0000

[email-masked] wrote:
> 
> Damon replied with:
> >If the app loads/receives an iCalendar file with, for example, a "Europe/London"
> >VTIMEZONE calendar component, and the user then creates another time with the
> Ok, Im probably too defocused on iCal right now but I do not quite grok the scenario fully.  I get an invite from Damon w/a VTIMEZONE in it for
> "Europe/London".  My CUA will crack open the incoming REQUEST and VTIMEZONE and converts it (at least internally) to, say, some UTC format relative to my
> default/configured TZ.  How then do I create "another time" (a different entry or REQUEST??) for "Europe/London" that utilizies a different definition of that
> TZ?  The new entry/event would utilize _my_ definition of "Europe/London" and when I send out REQUESTs it would contain _my_ VTIMEZONE for "Europe/London",
> not the one I received from Damon.
> 
> Ahh, is it the case that your CUA uses iCalendar as the native file format and it just stores the raw streams together in some indexed way???

Yes, we just save a user's calendar in one big iCalendar file.

>  I would
> stipulate that the CUA that does this needs to 'localize' the entry if it can to avoid problems like you are mulling over.  When I say 'localize' I mean TZ
> match and shift to its own definitions that match the ones coming in and use the matched defintions and change the date/time values accordingly before saving
> to a file.  Matching is not always a trivial task (ie: RRULE on the REQUEST but RDATEs in the CUA for the same TZ definition) but its not as hard as some of
> our other workflow cases (like Delegation chains)

If you have a complex, infinite RRULE I think it would be very difficult to convert
from one VTIMEZONE to another.

Even if it is possible, do we really want iCalendar to be this complex?

John said there may be a problem with iTIP if we rename TZIDs when they conflict.
Do you know if that is the case? If not, I'm hoping to do that.
The only other thing I can think of doing is just ignore conflicts (in the hope
that everyone is shipping perfect VTIMEZONE files).

Damon