Subject: (W-22) RE: Timezones and Olson Tables

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 14:30:55 -0700 (PDT)

> From: "IANA" <[email-masked]>
> Date: Wed, 28 Jul 1999 11:26:19 -0700
> 
>    (per Pat Egen) Keith wrote (in part):
>     - - - - - -
>
>     1. we need to make sure that everyone, including Olson, understands
>       and agrees on issues like copyright ownership, distribution rules
>       (presumably free to everyone), and change control

I have sent email to the ~owner~ of that database and Cc'd Pat Egen.
We will keep the WG informed of the status of the WG request to use
their data.

I believe that its free to all right now. I can not find a copyright
notice in any of the data. The 'sample code' has:

 Copyright (c) 1985, 1987, 1988 The Regents of the University of California.

However it is not the sample code that we would be using.

>     2. I think calsch should attempt to establish globally-scoped
>       timezone names, probably using different (or alternate) names
>       to those used in the Olson database.  If I understand correctly
>       Olson prefers to associate timezones with the names of continents
>       and nearby cities; but since most timezones are set by political
>       jurisdictions I suspect that we will get more precision (and the
>       timezones will be more "obvious") if we name the timezones after
>       the political regions for which those timezones are established.
>       So I would recommend that primary timezone names be: country code
>       for the top level of timezone name, followed by subdivisions
>       (for those few countries for which it is necessary), followed
>       very occasionally by ad hoc divisions when these are necessary.
>       E.g. /NO (for time in Norway) and /US/Eastern or /US/Indiana
>       (for time in Eastern US (EST/EDT) or the portion of Indiana
>       that always uses CST.  Note that the requirements for calsch
>       timezone names (which are mostly used to indicate events in the
>       future) may be different than those for the traditional uses of
>       the Olson database (which oddly enough are mostly used to
>       indicate events in the past - e.g. file modification times).

The Olson database address this issue by allowing 'aliases'.
For example US/Pacific is one name for a timezone. Because
'PST' is unsed more than once in the world. Thus 'PST' is not
in the database.

It might be easier if we just translate the data. There are a large
number of names for the same timezone.

As to future vs. past data. The Olson database tracks timezones
into the past. However it also seems to be up to date and is
valid for future information.

We might want to add Timezone aliases to iCalendar to address
these same issues.

>       Of course not all timezones are set by countries, so we would
>       still need a way to register other kinds of timezones.
>       Ideally countries could eventually get direct change control
>       over their timezone records at IANA.

That's the fun part :-)

>     - - - -
>     Ok list, comments, suggestions.  Doug, I know you have been working on
> this a lot.  Your thoughts?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Wed, 28 Jul 1999 22:33:02 GMT

>We might want to add Timezone aliases to iCalendar to address
You just enter more than one TZNAME property with different LANGUAGE 
parameters. No problem in the current spec.

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 16:21:35 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 28 Jul 1999 22:33:02 GMT
> 

Its not a LANGUAGE issue.  'PDT' and 'US/Pacific' could both be US-EN.

I mean that if an OS vendor calls it PDT, PST or PST8PDT or whatever
it can be mapped back to one definition, say US/Pacific:

Example using Olson names:

	BEGIN:VTIMEZONE
	TZID:US/Pacific			<- An Olson DB name 
	LAST-MODIFIED:19870101T000000Z
	BEGIN:STANDARD
	DTSTART:19971026T020000
	RDATE:19971026T020000
	TZOFFSETFROM:-0700
	TZOFFSETTO:-0800
	TZNAME:PST
	END:STANDARD
	BEGIN:DAYLIGHT
	DTSTART:19971026T020000
	RDATE:19970406T020000
	TZOFFSETFROM:-0800
	TZOFFSETTO:-0700
	TZNAME:PDT
	END:DAYLIGHT
	END:VTIMEZONE

Now one vendor may not call it US/Pacific on their OS. So,
if they could say something like:

	BEGIN:TZALIAS
	TZNAME:PST8PDT			<- Their name for the timezone
	TZID:US/Pacific			<- The standard name for the same tz.
	END:TZALIAS
	
I think this might solve some of the issues with multiple definitions.
For example PDT and PST in the 1st example as PDT and PST are also
used in other timezones around the world.

And this just happends to be the way the Olson DB solved the problem :-)

One of the problems faced by vendors is mapping the existing names
into new common standard names.  It just seems to me that it might be
more palatable if there was a standard way to map old names into a new
standard name.

If we do not, I foresee a fight over who gets to name the timezone.
I would like to avoid the fight and just use some name. Even
if we have to rename the timezone names in the Olson database.

-Doug

---

From: [email-masked]
Date: Thu, 29 Jul 1999 14:02:25 GMT

>                TZID:US/Pacific  <- An Olson DB name 

Incorrect sytax, if this is a reference to the registered standard time 
zone. RFC2445 indicates that:
"The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, 
indicates that this TZID represents an unique ID in a globally defined 
time zone registry (when such registry is defined)."
It would appear that we are preparing to define such a registry.
-- Frank

---

From: [email-masked]
Date: Thu, 29 Jul 1999 14:04:17 GMT

>I think this might solve some of the issues with multiple definitions.

Yes, this is conformant with RFC 2445. It correctly reflects the semantics 
for "TZNAME".
-- Frank

---

From: [email-masked]
Date: Thu, 29 Jul 1999 14:10:46 GMT

>Yes, this is conformant with RFC 2445. It correctly reflects the 
>semantics for "TZNAME".
>-- Frank
Egads. Check that! Sorry, just read the "TZALIAS"! Obviously, your example 
is _not_ conformant to RFC2445. I don't really see a need for adding 
another calendar component for the time zone aliases. Specifying multiple 
"TZNAME" properties is already allowed by RFC2445.
If you changed this to:
        BEGIN:VTIMEZONE
        TZNAME:US, Pacific Time
        TZNAME:PST8PDT
        TZNAME:US, Laid-back west coast time, man!
        TZNAME:US, PST Yada, yada, yada time
        TZID:/US/Pacific
        ...
        END:VTIMEZONE
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 Jul 1999 10:21:39 -0700 (PDT)

> Date: Thu, 29 Jul 1999 14:10:46 GMT
> 

Better idea - thanks!

-Doug