Subject: Re: Timezone TZID clashes

From: [email-masked]
Date: Tue, 20 Mar 2001 18:38:30 -0500

Damon replied:
>> 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.

Ahh, this sounds like an architecture issue due to how you 'merge' two 
potentially different VCALENDAR streams which is something we did not 
describe or focus on...  Hmm, why not simply concatenate the VCALENDAR 
streams into 2 serial ones so that the VTIMEZONE info is unique and 
accurate for the VTIMEZONE that contains it?

If you are not going to normalize the entry then you are going to get into 
TIMEZONE management hell as you get invites from all over.

>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?

Hence my suggestion to restrict the range of the VTIMEZONE to only that 
which bounds the affected entries.  For the more common "Lets meet for the 
next 25 Mondays" case this works fine.  I think the "Lets meet every 
Monday and Thursday from now until Armagedon" is less likely.  As such, 
matching is going to be something that should be tried and will probably 
have a good chance of working; esp. if we tightly restrict VTIMEZONEs from 
being infiinte (or even 500 years longer than the entries repeat set).

>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.

I do not believe there is an iTIP problem here.  The REPLY message is not 
an EXACT copy of the original REQUEST; in fact it does not return all the 
properties so its not an issue.  The COUNTER case is not relevant as the 
COUNTER is a full snapshot of the persons intended date/time/TZ, etc so 
different TZIDs are not an issue.   Perhaps John thinks that when I 
delegate to him I MUST send the byte-for-byte copy of the REQUEST but 
thats not true.  First off, I have to modify it so that I can add/modify 
the ATTENDEE properties.  Second, we have never mandated exact binary 
preservation or else iCalendar is not an on-the-wire format but an on-disk 
format and that wont fly w/existing systems.

So, if I delegate to John and my system has normalized your entry and 
matched your "Europe/London" to my own "UK/London" then I can quite easily 
send the delegation REQUEST to John using my "UK/London" TZ info.

>The only other thing I can think of doing is just ignore conflicts (in 
the hope
>that everyone is shipping perfect VTIMEZONE files).

You can try this as long as you dont charge lots of $$ to your users for 
your product.  Otherwise you can wind up with some pretty irate folks. :^)

Anyone got a prelim copy of Dougs tool that did Olsen->iCalendar?  I 
looked and couldn't find it.  If so, I suggest they post it to the list so 
we can all start w/a common set of values.  Perhaps you can post any tools 
you have already made to do this...

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: David Madeo <[email-masked]>
Date: Tue, 20 Mar 2001 19:05:13 -0500

> >If you have a complex, infinite RRULE I think it would be very
> difficult to convert
> Hence my suggestion to restrict the range of the VTIMEZONE to only
> that which bounds the affected entries.  For the more common "Lets
> meet for the next 25 Mondays" case this works fine.  I think the "Lets
> meet every Monday and Thursday from now until Armagedon" is less
> likely.  As such, matching is going to be something that should be
> tried and will probably have a good chance of working; esp. if we
> tightly restrict VTIMEZONEs from being infiinte (or even 500 years
> longer than the entries repeat set).

> looked and couldn't find it.  If so, I suggest they post it to the
> list so we can all start w/a common set of values.  Perhaps you can
> post any tools you have already made to do this...

Something which the olsen tzdata mailing list is all too familiar with
is that timezone definitions continually change.  My particular burden
is Brazil which changes the dates on which they switch to DST on a
yearly basis.  So, if there was a conference call in Sao Paulo on
Mondays at 2pm that I want to dial into regardless of what time it is
where I am, I am going to have to realize that the VTIMEZONE rules will
change during the life of the event.   I sure hope you didn't convert
the event into UTC when storing it...

dmadeo

---

From: Damon Chaplin <[email-masked]>
Date: Wed, 21 Mar 2001 21:34:05 +0000

[email-masked] wrote:

> Anyone got a prelim copy of Dougs tool that did Olsen->iCalendar?  I looked and couldn't find it.  If so, I suggest they post it to the list so we can all
> start w/a common set of values.  Perhaps you can post any tools you have already made to do this...

I've just updated my Olson->VTIMEZONE converter at: 

 http://www.karuna.freeserve.co.uk/vzic.tgz

The resulting VTIMEZONES are at:

 http://www.karuna.freeserve.co.uk/vtimezones.tgz

Let me know if you spot any errors.

Damon