Subject: Re: RDATEs in VTIMEZONEs

From: [email-masked]
Date: Thu, 3 May 2001 15:39:33 -0400

[email-masked] wrote on 05/02/2001 03:01:29 PM:
> > Wait a minute... Hmm, now that I mull it over I can see why UTC
> > actually may be a better answer though.  I dont want, say, Los Angeles
> > to incorrectly use 2AM PST/PDT as the shift time for New York who
> > actually shifted at 2AM EST/EDT!  The shift for New York occurs at
> > 11PM PST/PDT the day before!!!  So by using UTC it makes compensating
> > for shifts in other TZs correct...
> 
> I'm not sure I understand the problem.
> 

Ok, Ill go for the graphical explaination to see if that helps.  I have a 
VTIMEZONE that is:

BEGIN:VTIMEZONE
TZID:US-Eastern
LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD
DTSTART:20001026T020000
RDATE:20011026T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20001026T020000
RDATE:20010401T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE

The times are in local since the changes are relative to that TZ, not to 
any other TZ.  That is to say, New York City shifts at 2AM on 01-Apr-2001 
WRT NYC's local time; NOT at 2AM LA time.  Yes?  As such an LA CUA would 
have to be able to look at a local DTSTART;TZID=US-Eastern and map it 
(using the VTIMEZONES) to LAs time.  If both the LA and NYC VTIMEZONES 
were in local time then the CUA has to do extra work to match the LA 
shifted date/times with the NYC shift before it can finally decide what 
the actual LA occurance time actually is. 

In concrete terms: a 01:59 01-Apr-01 NYC event begins at 22:59 30-Mar-01 
LA time but a 03:01 01-Apr-01 NCY event begins at 23:01 30-Mar-01.  In LA 
only 2 minutes have passed but in NYC 62 have.  If the VTIMEZONE info was 
in UTC then it becomes a quicker action for the CUA to detect this.  The 
CUA in LA will have to convert the NYC relative TZ info to UTC and then 
use that to convert the actual entry date/time to UTC and then convert 
again to LA relative time (or just keep it at UTC so that it can apply its 
own TZ shifts accordingly too).  So, since all CUAs will have to do the 
"convert XYZ relative TZ info to UTC", why not simplify their load and 
just have the TZ info in UTC already?...

> I don't think the VTIMEZONE should be interpreted in any other timezone.
> A local RDATE would mean using the UTC offset that is in effect before
> the time change (i.e. from the other components in the VTIMEZONE).
> 
> DTSTART values must be local times in VTIMEZONES as well.

A VTIMEZONE must be interpretable in other time zones otherwise it would 
not be feasible to use them to schedule, say, a conference call between 
myself, Frank (in Dallas) and Steve (in San Jose) since we are all in 
different TZs.  Conveying the TZ information just w/in the zone is not 
that useful since all the CUAs in that TZ probably have the same settings 
(unless you are scheduling between, say, Arizona and Nevada).  From 2445, 
p62: 

   Interoperability between two calendaring and scheduling applications,
   especially for recurring events, to-dos or journal entries, is
   dependent on the ability to capture and convey date and time
   information in an unambiguous format.

Which is less ambiguous: UTC or a relative date/time?  Id say UTC is the 
least amiguous since relative date/times require knowledge of their source 
TZ.

Having to swap back and forth between deep issues like this and real work 
is more than a bit distracting so if Im way off on some rationale I expect 
Frank or Steve to whack me up-side the head and say "You forgot the case 
of..." and all will be better.  Ya know, it all seemed logical before that 
Reefknot talk on Tuesday... ;^)

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: Thu, 03 May 2001 16:13:13 -0400

[email-masked] wrote:

> The times are in local since the changes are relative to that TZ, not to any other TZ.  That is to say, New York City shifts at 2AM on 01-Apr-2001 WRT NYC's local time; NOT at 2AM LA time.  Yes?  As such an LA CUA would have to be able to look at a local DTSTART;TZID=US-Eastern and map it (using the VTIMEZONES) to LAs time.  If both the LA and NYC VTIMEZONES were in local time then the CUA has to do extra work to match the LA shifted date/times with the NYC shift before it can finally decide what the actual LA occurance time actually is.

Oh, I see. You didn't really mean it would be incorrect to use local times.
Just slower.

I'm not sure if it makes enough difference to worry about. If you know
what the UTC offset is it is pretty quick to switch back and forth from
local to UTC time.

I am more concerned with making sure we are compatable with Outlook
(and maybe Notes). So I'd rather do whatever they do already.

(Actually I'll probably add support for local and UTC times, to be sure.)

Damon