Subject: Re: Timezone TZID clashes

From: [email-masked]
Date: Mon, 19 Mar 2001 16:18:11 -0500

Damon proposed:
>It would be better if the VTIMEZONE components had a PRODID property
>and the LAST-MODIFIED property was made mandatory. We could then compare
>VTIMEZONES by just comparing the PRODID and LAST-MODIFIED.

This wont fix the problem, just move it around a bit.  If a VTIMEZONE is 
updated to reflect additions instead of a change to an existing VDAYLIGHT 
or VSTANDARD then the LAST-MODIFIED would be different.  As such, a 
sub-component by sub-component comparison would still be necessary to 
detect that only an addition was really made.

Also, given the hackery that goes on in HTTP land with User-Agent and 
various tools/download managers/etc I would NOT want to rely on PRODID as 
a key for doing detection/comparison.

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: [email-masked]
Date: Mon, 19 Mar 2001 16:41:09 -0500

John wrote:
>Besides, what happens if the recipient COUNTERs with a time outside that
>original range, a time at which the original VTIMEZONE disagrees with the 
reduced
>one?

Not an issue.  The COUNTER is not relative to the REQUESTs TZ, it can be 
ANY date/time the ATTENDEE wants to COUNTER with.  As such, it would use 
and send its own VTIMEZONE definitions, not reuse the REQUESTs.

Bruce

---

From: [email-masked]
Date: Tue, 20 Mar 2001 19:22:21 -0500

Dave responded with:
> 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.

They are not alone.  France does the same thing last I heard. 

How do you think a CUA in Brazil or France is supposed to book an entry 
that repeats that far out, say monthly for the next 5 years??  I can only 
see 2 choices:

1: It is going to have to be smart about 'readjusting' any entrys that it 
rolls out now to the 'new' date/time.  or
2: It wont be possible to create entries beyond the next expected (or 
known) TZ shift.

Bruce