headers
Keith Moore | 6 Aug 1998 02:57
Picon

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

> * A more consistent naming strategy for TZIDs.  The current draft is
>   inconsistent: for the same time zone it sometimes says
>   "America-New_York", sometimes "America-New York", and sometimes
>   other things like "Eastern".  TZIDs are arbitrary, but a good naming
>   convention can help reduce the number of errors, ease maintenance,
>   and improve interoperability.

What I'd really like to see is a separate document defining
globally-scoped timezone names.  That way, TZIDs don't have to be
arbitrary.  I would think that such a document would want to use a
subset of the names in the Olsen database.  e.g. "/US/Eastern"

> * A reference to the Olson database prior art.  Many potential
>   implementers don't know about this useful source, and have thereby
>   propagated incorrect time zone data.

I agree that this would be useful.

> * Allow UTC offsets that are not multiples of one minute.  This is
>   needed for historically recent applications (e.g. the time zone in
>   Liberia up to 1972).
>
> * The examples should be a tad more careful about distinguishing
>   between US Eastern time and New York time, since there was a lot of
>   confusion about the Eastern time zone before, say, 1976.

These also seem appropriate.

Keith
(Continue reading)

Permalink | Reply | 10 comments |
headers
Anik Ganguly | 8 Aug 1998 19:57
Picon
Favicon

Agenda for Chicago

Hello all,

	With a little luck iCalendar, iTIP and iMIP will be RFCs by the time we
meet in Chicago!

	Here are the items I would propose for the agenda. 

Agenda
------

1. CAP Requirements discussion, CAP discussion

2. iRIP closure?

3. Locating closure?

Please post your comments to the list.  I'll be off E-mail, on vacation
until Aug 17th. I'll collect your feedback and create the agenda after I
return.

###
Permalink | Reply | 1 comment |
headers
Pete O'Leary | 8 Aug 1998 23:10

RE: Time zone suggestions for draft-ietf-calsch-ical-08.txt

Keith,

I assume you mean globally-scoped names together with their corresponding
VTIMEZONE component?

I think this is a really good idea as well, but it's a fairly signifigant
undertaking. There is alot of information in the Olson work than needs to be
converted into iCalendar VTIMEZONE format. From the looks of it, this could
be done semi-automatically.

Any takers? I could be impelled into leading this effort, but I think we'll
need to discuss the scope of this in Chicago.

Pete.

> -----Original Message-----

> > * A more consistent naming strategy for TZIDs.  The current draft is
> >   inconsistent: for the same time zone it sometimes says
> >   "America-New_York", sometimes "America-New York", and sometimes
> >   other things like "Eastern".  TZIDs are arbitrary, but a good naming
> >   convention can help reduce the number of errors, ease maintenance,
> >   and improve interoperability.
>
> What I'd really like to see is a separate document defining
> globally-scoped timezone names.  That way, TZIDs don't have to be
> arbitrary.  I would think that such a document would want to use a
> subset of the names in the Olsen database.  e.g. "/US/Eastern"
(Continue reading)

Permalink | Reply | 9 comments |
headers
Keith Moore | 8 Aug 1998 23:49
Picon

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

> I assume you mean globally-scoped names together with their corresponding
> VTIMEZONE component?

Yes, that's what I had in mind.  But just defining the format of the
global timezone names themselves would be a useful first step.

(Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
is the iso 3166 country code and yyy is a political subdivision
within that country.  In many cases just /XX suffices.  
This probably doesn't cover all timezones that one might want to 
define, but it's a start.)

-Keith
Permalink | Reply | 7 comments |
headers
Paul Eggert | 9 Aug 1998 00:57

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

   From: "Pete O'Leary" <poleary <at> amplitude.com>
   Date: Sat, 8 Aug 1998 14:10:23 -0700

   There is alot of information in the Olson work than needs to be
   converted into iCalendar VTIMEZONE format. From the looks of it,
   this could be done semi-automatically.

   Any takers?

On July 16 Antoine Leca <Antoine.Leca <at> renault.fr> wrote that he is
doing exactly that, though my impression was that he is doing it
automatically, not semiautomatically.  You might contact him to see
what his current status is.  It should be a simple matter of hacking
the existing zic parser.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 9 Aug 1998 00:52

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

   From: Keith Moore <moore <at> cs.utk.edu>
   Date: Sat, 08 Aug 1998 17:49:54 -0400

   (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
   is the iso 3166 country code and yyy is a political subdivision
   within that country.  In many cases just /XX suffices.  

Why not just stick with the names already in the Olson database,
preceded by `/' if necessary for the new standard?  The Olson names
are widely used existing practice, and I don't see a technical reason
to change them.

If the ``don't mess with success'' argument is not enough to convince
you, then let me explain why the Olson names are the way they are;
perhaps that will help.

I originally tried using an /XX/yyy style naming convention when I was
designing the naming scheme currently used by the Olson database, but
I discovered several problems with /XXX/yyy:

* Time zone rule boundaries are not well correlated with current
  political subdivisions.  For example, it is tempting to use `/US/IN'
  for US Eastern Standard Time without DST, as is currently practiced
  in most of Indiana, but that is incorrect, since part of Indiana
  _does_ observe DST.

* Indiana alone has hundreds of distinct time zone histories, only a
  few of which are in the Olson database due to its 1970 cutoff; as
  time goes on, more will need to be added to the Olson database.
  Even if we identified which subdivisions of Indiana would work for
(Continue reading)

Permalink | Reply | 6 comments |
headers
Keith Moore | 9 Aug 1998 04:16
Picon

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

>    From: Keith Moore <moore <at> cs.utk.edu>
>    Date: Sat, 08 Aug 1998 17:49:54 -0400
> 
>    (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
>    is the iso 3166 country code and yyy is a political subdivision
>    within that country.  In many cases just /XX suffices.  
> 
> Why not just stick with the names already in the Olson database,
> preceded by `/' if necessary for the new standard?  The Olson names
> are widely used existing practice, and I don't see a technical reason
> to change them.

Actually, when I suggested that '/' be the introducer for global
timezones, I had the Olsen database in mind, and have always assumed
that we should start with a subset of that database.

But if you're trying to define a standard for global timezone names,
it makes sense to think carefully about them and see if you want to
keep all of the Olsen timezone names.    Some of them don't seem
authoritative enough.

The Olson database has the (to me) undesirable property that there 
are a lot of aliases.  It seems like we would rather have "canonical" 
names when possible.  And the Olsen database tries to define names 
for everything.  It might be better to not define timezone names where 
we don't have really good solid authoritative information, or where
the local model of calendar doesn't quite fit with what iCalendar does.
(like places that use solar time)

> I originally tried using an /XX/yyy style naming convention when I was
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Eggert | 9 Aug 1998 08:27

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

   From: Keith Moore <moore <at> cs.utk.edu>
   Date: Sat, 08 Aug 1998 22:16:01 -0400

   The Olson database has the (to me) undesirable property that there 
   are a lot of aliases.

Those aliases are mostly the result of the transition of old-style
Olson names (e.g. US/Pacific) to the new-style names
(e.g. America/Los_Angeles).  Any new standard could omit the old-style
names; this would alleviate the problem of aliases.  Some of those old
names are popular, though....

   It might be better to not define timezone names where we don't have
   really good solid authoritative information, or where the local
   model of calendar doesn't quite fit with what iCalendar does.

If we insist on ``really good solid authoritative information'', then
I'm afraid coverage will be limited.  Nobody keeps track of this stuff
authoritatively on a world-wide basis.  Nobody even keeps track of it
authoritatively for Indiana!

People have called for official bodies to keep track of this stuff
authoritatively -- the ISO, or the UN, or the IATA, or somebody.
It hasn't happened, and I don't think it likely to happen soon.

   (like places that use solar time)

Nobody uses solar time any more for civil time.  The last holdout was
Saudi Arabia; they converted to UTC+3 in 1950.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Markus Kuhn | 9 Aug 1998 10:32
Picon
Picon
Favicon

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

Keith Moore <moore <at> cs.utk.edu> wrote on 1998-08-08:
>    (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
>    is the iso 3166 country code and yyy is a political subdivision
>    within that country.  In many cases just /XX suffices.  

I have only seen this short excerpt from your mail quoted by Paul on the
tz list, so I don't know whether you already know that there exists a
new ISO 3166-2 draft standard, which defines ISO alpha codes for
regional subdivisions within countries (e.g., the states in US and the
bundesländer in DE):

ISO 3166-1:1997, Codes for the representation of names of countries and their
subdivisions -- Part 1: Country codes 
ISO/DIS 3166-2, Codes for the representation of names of countries and their
subdivisions -- Part 2: Country subdivision code 
ISO/DIS 3166-3, Codes for the representation of names of countries and their
subdivisions -- Part 3: Code for formerly used names of countries 

Paul Eggert replied on 1998-08-08:
> Why not just stick with the names already in the Olson database,
> preceded by `/' if necessary for the new standard?  The Olson names
> are widely used existing practice, and I don't see a technical reason
> to change them.

I agree that naming a time zone after the most populated city within
that time zone is a very flexible and sound approach. The only thing
that irritates me about the Olson/Eggert tz names is that they are all
prefixed by the continent name, which I feel is redundant information.
Is there really a good rationale why it has to be "Europe/Berlin" for
the German time zone and not just "Berlin". I know that the tz database
(Continue reading)

Permalink | Reply | 1 comment |
headers
Antoine Leca | 10 Aug 1998 11:56
Picon

Re: Time zone suggestions for draft-ietf-calsch-ical-08.txt

Markus Kuhn wrote:
> 
> Keith Moore <moore <at> cs.utk.edu> wrote on 1998-08-08:
> >    (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
> >    is the iso 3166 country code and yyy is a political subdivision
> >    within that country.  In many cases just /XX suffices.
> 
> I don't know whether you already know that there exists a
> new ISO 3166-2 draft standard, which defines ISO alpha codes for
> regional subdivisions within countries (e.g., the states in US and the
> bundesländer in DE):

As Paul explained, this might be inappropriate.
For example, the finest degree for Indiana according to ISO DIS 3166-2
is US-IN, and this does not accord with current practice.

OTOH, there is Europe or the Western Indies... take a look below!

> I agree that naming a time zone after the most populated city within
> that time zone is a very flexible and sound approach. The only thing
> that irritates me about the Olson/Eggert tz names is that they are all
> prefixed by the continent name, which I feel is redundant information.
> Is there really a good rationale why it has to be "Europe/Berlin" for
> the German time zone and not just "Berlin".

First, I should say that I see no reason to invent a new scheme:
better to not always reinvent the wheel!

Well, my problem is that, *in the view of the iCalendar protocol*,
adding a different entry for each country may be an unnecessary burden.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane