[Ietf-calsify] Timezone registration

[MRC at CAC.Washington.EDU (Mark Crispin)]

Suggestion:

Consider the registry not of timezone, but of daylight savings time rules.

Thus, instead of my local time zone being "US Pacific time", it would be 
-0800 with the "US/1987" daylight savings time rule (soon to be replaced 
with the "US/2007" rule).

There can also be some syntax (but not a registered rule!) that indicates 
"contemporary rule for that time".  In other words, something like "-0800 
US" would mean something different in 1986 than today, and in turn it 
would mean something different in 2007.

It needs to be emphasize the latter is not a registered rule, but rather a 
shorthand for a registered rule, and which generally can not be relied 
upon (hence you should use a registered rule such as -0800 US/1987").

Excuse me if this sort of this has already been considered and rejected.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
From MRC at CAC.Washington.EDU  Mon Aug  8 22:40:24 2005
From: MRC at CAC.Washington.EDU (Mark Crispin)
Date: Fri Aug 12 16:00:21 2005
Subject: [Ietf-calsify] Timezone registration
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Mon, 8 Aug 2005, Lisa Dusseault wrote:
> That's not a bad scheme but unnecessary with iCalendar.  In iCalendar you can 
> define a timezone that is -0800 from 1987 until 2007 and then something else 
> from 2007 onward.

Huh?  The US Pacific time zone will still be -0800 after 2007.  The only 
thing that changes is four additional weeks of summer time (at -0700).

> In fact it's necessary to put both the pre and post-2007 
> rules into one timezone because a meeting that recurs over a time period that 
> crosses from 2006 into 2007 needs to have its recurrences calculated out 
> according to both the old and the new DST rules.

Not necessarily so.  If a meeting takes place with attendees in multiple 
time zones, an adminstrative decision has to take place with each decree 
of a new rule to determine who has to adjust.

For example, if you have a regularly scheduled teleconference between New 
York and London, and the rule in the US changes, do the Londoners have to 
adjust or do the New Yorkers?  What if the rule in the UK changes?  Maybe 
it depends which city has the head office.

Hence the desirability to register a *rule*, independent of a timezone. 
Among other things, that means that that you only have to register 1 new 
rule for the US change in 2007, not one for each US time zone.

> I quite liked what I heard from Patrik at the meeting, that people actually 
> schedule meetings with reference to the time in a particular *place* rather 
> than in a particular timezone.

Correct.  "America/San Francisco" is in effect, what "-0800 US/1987" is; 
"the -0800 timezone with the US 1987 summer time rule".

However, I think that it is madness to register names such as "America/San 
Francisco" since it doesn't scale.  Such names are OK as friendly alias 
names; nothing prevents a program from having "San Francisco time" as 
adhering to a particular set of rules.  But those should not be the rule 
names themselves.

Otherwise, you have the situation where I'm forced to set a Seattle time 
rule as being "San Francisco" because some programmer didn't think that 
Seattle was important enough, and then if in the future there is a 
difference the schedule gets screwed up.  Worse, if I can't add Seattle 
separately I can't fix it because that would break the San Francisco 
schedules.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
From julian.reschke at gmx.de  Tue Aug  9 02:08:31 2005
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Aug 12 16:00:21 2005
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Doug Royer wrote:
> 
> 
> The xCal draft has been rewritten and submitted to the IETF.
> 
> I have an XSLT translation file that I will be releasing
> soon on SourceForge that can translate an xCal object
> back to an iCal object. I am waiting for SourceForge
> to approve the project name.
> 
> Discussion takes place on [e-mail]
> 
> Copies of the draft at:
> 
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> 
> 
> JOIN the xCal mailing list at:
> 
>     http://inet-consulting.com/mailman/listinfo/xcal
> 

Just two quick formal comments...:

1) Is it intentional that in the examples, the iCalendar container 
element is in no namespace?

2) I don't think the IETF will let you use something like 
"http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Best regards, Julian