Subject: Re: supposing one would want to create a new URN space for timezones...

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 12:54:57 -0500

On Tue, Mar 31, 2009 at 07:46:43PM -0700, Allison Mankin wrote:
> ISO doesn't register timezones now, I think, but I imagine some
> diplomacy would still be in order - I'd be happy to help with
> that via JTC1/SC6.

Well, SJ Kissane points out that the Unicode Consortium does define
timezone names.  So perhaps we should start with that, and maybe even
stop there and just define timezone URNs by reference to the Unicode
standards.

Nico
--

---

From: Allison Mankin <[email-masked]>
Date: Tue, 31 Mar 2009 19:46:43 -0700

> 
> Well, creating an IANA registry might force ISO's hand, who knows.  The
> registration rules for the registry might be such that the IETF/ISO
> JTC1/SC6 liason would have to certify submitters.  But most likely the
> ISO would want to define the timezone naming scheme(s), at least as to
> country-specific timezones...
> 
> In any case, I think asking the IETF/ISO liasons is the correct first
> step for an IETF participant interested in addressing these problems.
> I've decided to cc the currently listed IETF/ISO JTC1/SC6 liason,
> Allison Mankin.
> 

I agree with the instinct to check up and communicate. 

Allison

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 15:47:46 -0400

> stop there and just define timezone URNs by reference to the Unicode

depends on how good a job they did.

---

From: SJ Kissane <[email-masked]>
Date: Thu, 2 Apr 2009 12:49:56 +1100

2009/4/2 Keith Moore <[email-masked]>

> depends on how good a job they did.
I think the intention of the Unicode project was to have unique identifiers,
for use in data formats and protocols (XML, Web Services, databases,
whatever).
So, they picked the Olson identifiers, rather than reinvent the wheel, but
choose to ignore renames, to make the identifiers more stable over time.
Some of the names may be imperfect, even plain wrong, but its not an issue
because these names are not meant for direct display to the user -- they are
meant
just as identifiers. The CLDR defines mapping tables, for user-friendly
names of
these identifiers in various languages. The identifiers are fixed
permanently, but the
mapping tables can be changed from version to version.

If someone thinks the mapping tables are imperfect, they can always contact
the
CLDR project and suggest changes / revisions.

There have been some comments above, that people would prefer a pick a
country and
state province to find the timezone, rather than a city.
Well, Olson already contains a mapping file for ISO-3166-1 codes to
timezones.
Of course, this is not a 1-1 mapping, since multiple countries share the
same timezone,
and the same country has multiple timezones.

Maybe a useful addition, would be to map to ISO-3166-2 codes as well?
So then, you can find the Timezone for Kentucky, USA.
BUT, even this is not a 1-1 mapping, because sometimes the same
state/province has multiple time zones.

Example: The State of New South Wales in Australia has 3 timezones
- UTC+10 / +11 in most of the state
- UTC+9.5 / +10.5 in Yancowinna County [Broken Hill and the surrounding
area]
- UTC+10.5 / +11 on Lord Howe Island
So, even picking Australia > NSW in a user interface, you still have 3
choices of timezone
(although, 99%+ of the state population and area is in the main one, still
you wouldn't
want to alienate those people who live in the other two...)

This is why City, Continent like Olson uses is a better choice than
Country>State/Province.
Because at least down to the county/municipality level, you can have a
different timezone in
some cases, but you wouldn't want to list every county/municipality in the
world in your
timezone database...

Cheers
Simon

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2009 01:13:40 -0400

SJ Kissane wrote:

I think the intention of the Unicode
project was to have unique identifiers,

So, they picked the Olson identifiers, rather than reinvent the wheel,
but

Some of the names may be imperfect, even plain wrong, but its not an
issue

because these names are not meant for direct display to the user --
they are  meant just as identifiers.

I'd almost agree with you, except that the Olson/CLDR identifiers are
so poorly chosen that it seems likely that they will break.  Let me
give an example.  There have, over the years, been serious discussion
as to whether the city of Chicago, IL should move to the Eastern time
zone.  If (as I think is the case) America/Chicago is the canonical
name for the Central time zone in the US according to CLDR
canonicalization rules, and should Chicago move to the Eastern time
zone, an unavoidable tension results - does America/Chicago mean
"Central time zone" (to preserve the old meaning) or does it mean "the
time zone in use in the city of Chicago?"

There have been some comments above,
that people would prefer a pick a country and

Of course, this is not a 1-1 mapping, since multiple countries share
the same timezone, and the same country has multiple timezones.

Indeed, the state I live in (Tennessee) has two time zones.  So clearly
we don't want to do this entirely using state names.

Example: The State of New South Wales
in Australia has 3 timezones

So, even picking Australia > NSW in a user interface, you still have
3 choices of timezone (although, 99%+ of the state population and area
is in the main one, still you wouldn't want to alienate those people
who live in the other two...)

However, if you use default GMT offset along with country code (and
state name when needed) you get a naming scheme which comes very close
to covering all timezones in current use.  E.g. "+1000.AU.NSW" to mean
"the timezone with default GMT offset of +1000, using the summer time
rules in effect in the state of New South Wales in the country of
Australia."

This is why City, Continent like
Olson uses is a better choice than Country>State/Province.

nope.   Not only do cities sometimes change timezones (most often
because of realignment of political boundaries), the area that shares a
particular city's timezone often changes also.   Using a city name as a
canonical timezone name is exactly the wrong thing to do for any event
held outside that city.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 09:56:25 -0500

On Thu, Apr 02, 2009 at 01:13:40AM -0400, Keith Moore wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<whine>
Really, HTML e-mail on a mailing list?
</whine>

> > I think the intention of the Unicode project was to have unique
> > identifiers, for use in data formats and protocols (XML, Web
> > Services, databases, whatever).  So, they picked the Olson
> > identifiers, rather than reinvent the wheel, but choose to ignore
> > renames, to make the identifiers more stable over time.
> > 
> > issue because these names are not meant for direct display to the
> > user -- they are&nbsp; meant just as identifiers.
> 
> so poorly chosen that it seems likely that they will break.&nbsp; Let me

Doesn't matter -- it suffices that the CLDR provides user-friendly
aliases.

I don't care at all what the canonical timezone names look like -- I
hate <region>/<city>, as I'm sure I've made clear by now, but I don't
mind at all the use of <region>/<city> as a canonical form provided
that: a) conflicts are avoided/resolved, b) there are alternative,
user-friendly aliases including localization.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2009 16:47:25 -0400

> Really, HTML e-mail on a mailing list?

Sorry, I thought my MUA was configured to not do that.

> Doesn't matter -- it suffices that the CLDR provides user-friendly

I consider that irrelevant to the question at hand.

Keith