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

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2009 15:39:47 +0200

... would this amount to a new NID, or is there someplace we should hang 
this?

My thinking by the way would be something like the following:

...:TIMEZONE:Authority:Timezone Name

where authority would be (at least initially) one of three things:

1.  Olson
2.  IEEE
3.  Microsoft

The need for interoperability dictates one preferred method, which IMHO 
should be Olson.

Thoughts?

Eliot

---

From: Timur Shemsedinov <[email-masked]>
Date: Mon, 30 Mar 2009 16:33:34 +0200

It's a good idea, I am in need of such URN for a long time.
But I must note that:
1. Timezones are independent from authority. Timezones regulation is in
jurisdiction of local government of each territory.
2. Timezones are not stable from year to year, regulation can be changed by
local government.
3. Timezones are related to Lat/Long coordinates, so we can resolve Lat/Long
to timezone.
4. Daylight saving time should be considered too.
5. Which language do you prefer to name timezones? English / why not local
languages?

I have following proposition:
1. Combine time, geographical coordinates and timezones in one URN
2. Develop mechanism for resolving Lat/Long to Timezone and backward, global
time to local time and backward

On Mon, Mar 30, 2009 at 3:39 PM, Eliot Lear <[email-masked]> wrote:

> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 30 Mar 2009 10:44:40 -0400

Hi Eliot,

> The need for interoperability dictates one preferred method, which IMHO

First point: we should refer to Olson, Microsoft etc as "publishers" not 
"authorities". "Authorities" are the actual governments or other equivalent 
bodies that make the rules defining a timezone.

The other thing is that at CalConnect we see the need for timezone names 
that all publishers can agree on that allow correlation of timezone 
published by each. As such a registry of timezone ids independent of 
publisher is needed. Something like:

urn:tzid:<<tzname>>

or perhaps with a uuid instead of the name (to avoid "political" issue wrt 
timezone languages, government recognition etc).

There should then be a separate registry of timezone publishers. Then a 
"fully qualified" timezone identifier could include the publisher name as 
well - but that would be optional.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2009 16:55:07 +0200

Cyrus,

Thanks.  Please see below:

On 3/30/09 4:44 PM, Cyrus Daboo wrote:
>
> First point: we should refer to Olson, Microsoft etc as "publishers" 
> not "authorities". "Authorities" are the actual governments or other 
> equivalent bodies that make the rules defining a timezone.

Clearly not authorities as it has already caused confusion.
>
> The other thing is that at CalConnect we see the need for timezone 
> names that all publishers can agree on that allow correlation of 
> timezone published by each. As such a registry of timezone ids 
> independent of publisher is needed. Something like:
>
> urn:tzid:<<tzname>>
>
> or perhaps with a uuid instead of the name (to avoid "political" issue 
> wrt timezone languages, government recognition etc).

URN can't have is one name resolving to two values.  I think resolution 
would cause the same concerns you are fighting today.  An alternative 
would be to reference the publisher within the standard and update that 
as might be required in the future.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 30 Mar 2009 11:02:56 -0400

Hi Timur,

> jurisdiction of local government of each territory.

Right. I prefer to use the term "publisher" to describe the source of 
timezone data.

> 2. Timezones are not stable from year to year, regulation can be changed
> by local government.

Absolutely - what is more changes can occur at very short notice (sometimes 
only a few weeks) Any timezone publishing service needs to be able to react 
quickly.

> 3. Timezones are related to Lat/Long coordinates, so we can resolve
> Lat/Long to timezone.

I prefer to leave Lat/Long out of timezones definitions - the timezone 
definition should be just the offset and DST rules only plus the 
identifier. A separate service can then be used to map lat/long to tzids as 
needed (e.g. <http://www.geonames.org/export/web-services.html#timezone>). 
This makes sense because different geographic areas often adopt timezones 
from other areas over time. Plus defining lat-long is complex - its not 
just a single point - you need to describe a geographic area - i.e. 
polygons - and include "exclusions" for areas nested inside others.

> 4. Daylight saving time should be considered too.

That is implicit in a timezone definition (at least as far as iCalendar 
RFC2445 data is concerned).

> 5. Which language do you prefer to name timezones? English / why not
> local languages?

Internationalization of timezone names is an issue. That is why we may need 
to go with some for of uuid to identify unique timezones - then define a 
separate mapping to localized names for each of those.

> 2. Develop mechanism for resolving Lat/Long to Timezone and backward,
> global time to local time and backward

Lat/long can be covered by services like 
<http://www.geonames.org/export/web-services.html#timezone>.

For timezone data itself CalConnect is working on an XML data format (based 
on RFC2445 type rules and Olson style zone/rule data) that would be used to 
define ongoing and historic  offsets and DST rules. The goal is to make 
this compatible with RFC2445 VTIMEZONE data as well as Olson and make it 
easy to derive zoneinfo files (as is done today direct from Olson data).

Hopefully the work that CalConnect has done will be submitted to the IETF 
in the form of a set of drafts within the next month or two so that we can 
move discussion over to the IETF for proper standardization. In addition to 
registries we are also working on a RESTful HTTP service for retrieval of 
timezone information from a "provider" - that service includes some rich 
apis to allow "thin" clients to retrieve offset information directly from 
the server, avoiding the need for those clients to actually handle the 
sometimes (often) complex rules involved in DST.

-- 
Cyrus Daboo

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Mar 2009 08:36:16 -0700

> separate mapping to localized names for each of those.

AFAIK, the canonical timezone name is a string which contains the publisher
name and is unique in the publisher's namespace. It can be in some natural
language or it can be a UUID, but that is up to the publisher.  There can be
lots of other names for the timezone in various natural languages, but the
publisher gets to pick a name that the computer uses.

thanks,
-rohan

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 10:49:30 -0500

I guess I have to wonder how to get the persistence we expect from URNs
when using them to name timezones.  The problem is that timezone
boundaries change over time.

Say, for example, you define a timezone named X and at the time you
define it, it happens to apply to both City A and City B.  At some later
date, political boundaries change.  This causes timezone boundaries to
be realigned, and A and B are no longer in the same timezone.  This
creates a tension between different uses of name X - does it apply to
the timezone in city A or that in city B?

(Or even more subtly - say that the GMT offset for A and B remains the
same after the change, but the rules for transition to/from "summer
time" are different.  In this case it's even less clear which one is the
"old" timezone and which one is the "new" one.)

This kind of tension happens all the time with names for things, so
timezones really aren't exceptional in that regard.  The problem comes
when we try to make those names have URN semantics.

--

But if you really want to do this, I think you need to define them in
terms of political entities, because it's the political entities that
define the timezones.  Say:

URN:TZ:US.Eastern		US eastern time zone
URN:TZ:US.IN.central		timezone in central Indiana

Use ISO 3166 country codes because the binding between those and the
countries they refer to will be unambiguous.  e.g. Even if Bezerkistan
splits up into two separate countries and both of them claim
Bezerkistan's country code, ISO will presumably find some way to sort
things out.

I don't think the publisher should be part of the timezone URN, because
really you aren't trying to define an event in terms of the timezone as
published by Olson or IEEE or whomever -  you're trying to define an
event relative to whatever the US.Eastern timezone happens to be.

Keith

---

From: Tony Garnock-Jones <[email-masked]>
Date: Mon, 30 Mar 2009 17:06:27 +0100

> boundaries change over time.

They could be given in terms of publisher and edition.

 URN:TZ:Olsen:2009d:Europe/London

("Europe/London as defined by Olsen database version 2009d.")

That way, it's always unambiguous and stable in the face of evolution.

> define the timezones.

One could treat a political entity as a publisher. The edition string
then would be a reference to the law that introduced the definition:

 URN:TZ:US:T15.USC.6.IX.260a.19960116:PST
 URN:TZ:US:XO11751.38FR34725.19731215:PST

Yuck. I prefer Olsen's edition names :)

Regards,
  Tony

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Mar 2009 09:11:09 -0700

Keith,
There are two separate things we keep track of:
a) What geographic regions are in what timezone at a specific moment of
time. We are not discussing this case at the moment. Solving this is
hampered by the fact that more than one authority can claim rights to define
timezone rules for the same piece of ground (ex: Kashmir). The good news is
that usually a user or administrator picks a timezone and most timezones
don't have this problem.  Note that Indiana and Arizona do not move back and
forth from one time zone to another. They have their own timezones.

b) What the time offset rules are for a specific timezone. Timezone
publishers already keep track of when the rules for a specific timezone
change.  When the US recently changed the dates that daylight savings time
starts and ends, the timezone rules for US-Eastern, US-Pacific, etc. has
enough information to calculate both past and future times. Likewise, when
Brazil postponed the start of daylight savings time because the pope was in
town and someone forgot to calculate the change in offset when reserving
satellite time, the timezone rules in the Olson database reflect that
one-time historic event and can calculate dates and times correctly back to
1970.

This whole area is well studied by folks outside the IETF. If not a "solved"
problem it is basically a very well managed problem. What is not solved is
how to represent these timezones in a URN.

What many people realized is that the "authorities" are a lousy source of
timezone data and that is why the publishers exist. They exist because they
are independent and are only interested in delivering accurate timezone
information. Therefore people trust them more than anyone else to deliver
useful timezone information. If ever there is some disagreement between the
tz rules of two publishers, the user/administrator/programmer should be able
to pick one. Also there is no agreement on the canonical names among
publishers. Therefore it makes sense that the URN contain the name of the
publisher. This URN should be used by the computer only and only a
corresponding localized human readable string should be presented to the end
user.

thanks,
-rohan

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Mar 2009 17:14:09 +0100

On Mon, 30 Mar 2009, Keith Moore wrote:

> when using them to name timezones.

What properties do you want to be persistent? I can't think of anything
about timezones that has any guarantee of persistence. The only sure thing
is to refer to local time at a particular location, with a fairly
high-resolution concept of location (e.g. per county in many US states).
Unfortunately this makes the problem of tz naming thousands of times
larger than the number of distinct timezones.

> terms of political entities, because it's the political entities that

But which political entity is responsible for the time in a given location
is not stable, and furthermore the political arrangements are
unnecessarily obscure for the purpose of keeping tz rules.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 11:14:41 -0500

> That way, it's always unambiguous and stable in the face of evolution.

Then you won't recognize that two timezones are the same when they're
defined in terms of different publishers, or the same publisher and
different editions (even when the rules for that timezone didn't change
between editions).

Do you really want timezone identifiers that all change every time
somebody, somewhere in the world, changes the definition of a single
timezone?

(why do people want timezone URNs anyway?)

>  URN:TZ:US:XO11751.38FR34725.19731215:PST

The thing is, I don't think we want the notion of a timezone URN to
apply only to GMT offset and summer time transition rules that are/were
valid for a specific period of time.  I think we want the notion of
timezone to apply to the set of rules in place for a particular location
independent of any changes to those rules.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 11:17:31 -0500

Rohan Mahy wrote:
> hampered by the fact that more than one authority can claim rights to
> define timezone rules for the same piece of ground (ex: Kashmir). The
> good news is that usually a user or administrator picks a timezone and
> most timezones don't have this problem.  Note that Indiana and Arizona
> do not move back and forth from one time zone to another. They have
> their own timezones.
> 
> change.  When the US recently changed the dates that daylight savings
> time starts and ends, the timezone rules for US-Eastern, US-Pacific,
> etc. has enough information to calculate both past and future times.
> Likewise, when Brazil postponed the start of daylight savings time
> because the pope was in town and someone forgot to calculate the change
> in offset when reserving satellite time, the timezone rules in the Olson
> database reflect that one-time historic event and can calculate dates
> and times correctly back to 1970.
> 
> This whole area is well studied by folks outside the IETF. If not a
> "solved" problem it is basically a very well managed problem. What is
> not solved is how to represent these timezones in a URN.

yes, I understand all of the above.

> What many people realized is that the "authorities" are a lousy source
> of timezone data and that is why the publishers exist. They exist
> because they are independent and are only interested in delivering
> accurate timezone information. Therefore people trust them more than
> anyone else to deliver useful timezone information. If ever there is
> some disagreement between the tz rules of two publishers, the
> user/administrator/programmer should be able to pick one. Also there is
> no agreement on the canonical names among publishers. Therefore it makes
> sense that the URN contain the name of the publisher.

no, it doesn't follow.  because what the publishers are doing is still
trying to reflect the laws that are put in place by the authorities.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 30 Mar 2009 12:27:02 -0400

Hi Keith,

> somebody, somewhere in the world, changes the definition of a single

Right - and this is the critical point of interoperability that we want to 
solve in the Calendaring & Scheduling space. The key thing to remember is 
that "urn:tzid:Europe/London" contains the full historical information and 
current ongoing rules for that timezone definition. Clients/servers can 
then rely on that so that we can pass timezone data "by reference" instead 
of "by value".

iCalendar RFC2445 currently requires all appropriate VTIMEZONE objects to 
be included in a VCALENDAR stream that references a timezone - this results 
in a lot of duplicate data being sent each time a VCALENDAR object is 
exchanged

One goal for this work is to eliminate the need to send the actual 
VTIMEZONE data - instead we want the iCalendar objects to refer to the new 
"standard timezones" with the guarantee that each party on either side of 
the exchange of data has the exact same definition that they can rely on to 
calculate UTC times etc.

The publisher and version information would be meta-data included with the 
timezone data that "providers" (as per my apps area slides) make available 
to "consumers".

-- 
Cyrus Daboo

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 11:30:22 -0500

Tony Finch wrote:
> about timezones that has any guarantee of persistence.

The binding between a URN and the concept that it names needs to be
persistent.  Otherwise use of URNs is out of scope.

That doesn't say that if you use a URN to name a timezone, that the
rules associated with the timezone can never change, or that the areas
in which that timezone is used can never change.  But the binding
between the URN and the set of rules cannot change.  You can't say one
day that URN:TZ:FOO means US/Eastern time and the next day it means
US/Pacific time.

> is not stable,

It doesn't matter.  The location shouldn't be part of the timezone name,
as the set of locations to which a timezone refers can change over time,
and sometimes there is a dispute about which timezone applies to a
particular location.

A timezone is just a set of rules for calculating GMT offset.  They tend
to be defined by political entities and they are usually applied to
particular regions.   But there's no inherent relation between the
location of an event and any particular timezone.  If someone in Europe
wants to schedule a conference call at 4 pm US/Eastern time (say for the
benefit of an American participant), they're free to do so.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 11:39:09 -0500

Cyrus Daboo wrote:
> Right - and this is the critical point of interoperability that we want
> to solve in the Calendaring & Scheduling space. The key thing to
> remember is that "urn:tzid:Europe/London" contains the full historical
> information and current ongoing rules for that timezone definition.

I realize this is heretical in some circles, but I'll claim that
embedding the city name in a timezone name is a bug - or at least
suboptimal.  It doesn't seem so much like a bug when you use the name of
a major city such as London or Chicago, because everyone knows about
them and we don't expect them to split up.  And their is a tendency for
people to align their activities according to the timezone in a nearby
major city.  Still, for locations that aren't terribly close to a big
city, it's not always clear which definition applies, and the boundaries
at which a city's timezone applies tend to shift over time.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 30 Mar 2009 12:49:32 -0400

Hi Keith,

> at which a city's timezone applies tend to shift over time.

Right. That is one of the reasons I think I would prefer to have a uuid as 
the actual registered identifier with perhaps an "also known as" field in 
the registry with the Olson-style names. One of the roles of a timezone 
"publisher" or "provider" would be to include a mapping table from the 
uuids to localized names that can be presented to users - how that data is 
generated is out of scope for us - all that matters is that we provide the 
necessary apis and data fields to allow it to be used.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2009 19:49:02 +0200

Guys,

Realistically I don't think we get to have a say on how the publishers 
choose their keys for information.  I also don't think we get to tell 
them what language they do it in.  Doing so gets someone into a full 
time job just to keep the mapping between IANA names and their names.  
Let's not do that.  Introducing any coherency concerns would be bad.  
This needs to be light weight.  If you want to localize, do it in your 
implementation.

Eliot

---

From: Timur Shemsedinov <[email-masked]>
Date: Mon, 30 Mar 2009 21:33:00 +0300

On Mon, Mar 30, 2009 at 8:49 PM, Eliot Lear <[email-masked]> wrote:

> choose their keys for information.  I also don't think we get to tell them
> what language they do it in.  Doing so gets someone into a full time job
> just to keep the mapping between IANA names and their names.  Let's not do
> that.  Introducing any coherency concerns would be bad.  This needs to be
> light weight.  If you want to localize, do it in your implementation.

I believe that Timezones are same thing as NS so we need something like DNS,
including 4 things:
1. unique identification (URN)
2. Timezones database (or databases) to hold daylight saving, history on
mapping to territories and date periods. Such databases should be stored in
any format depending on realization but having unified fields.
3. resolving algorithm with common interface
4. resolving services implementing algorithm but compatible with each other

I think we need special RFC to regulate timezones resolution (based on ISO).

~Timur

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 30 Mar 2009 20:47:19 +0200

On 30 mar 2009, at 18.39, Keith Moore wrote:

> suboptimal.

Yes, but...

What you want to do when you use a timezone is to say that an event is  
at a specific time according to a specific timezone. How you name that  
timezone does not matter. Right? The mapping from locality/lat/long  
etc to timezone name can in theory be calculated. And this mapping  
might also change over time.

I think therefore in practice, as "events" often are bound to a named  
location that you want to go from that location (say London) together  
with time at that location to the time in UTC. So in reality you will  
probably have names of cities there...

    paf

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 14:18:50 -0500

> This needs to be light weight.  If you want to localize, do it in your

If I understand you correctly, I think you're saying that URNs are not
applicable for this problem.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 14:29:35 -0500

Patrik Fältström wrote:
> timezone does not matter. Right? 

I think it's easy to name time zones in such a way as to cause confusion.

> The mapping from locality/lat/long etc to timezone name can in theory be calculated. And this mapping might
> also change over time.
> 

London is a misleading example.  What happens if the event is in
Crossville, Tennessee?  It's very close to the boundary between Eastern
and Central timezones in the US.  Should they be forced to choose
between naming their events after the time in Chicago or New York?  They
might not even know that Chicago is on Central time in the US, but they
do know that their local timezone is Central time.  (and there's been
talk from time to time about Chicago moving to Eastern time to better
align itself with New York...)

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 30 Mar 2009 21:33:34 +0200

> align itself with New York...)

First of all, I think the publisher of the timezone information should  
be able to decide on whatever namespace they want to use. That is sort  
of the competition between publishers, right?

Secondly, I think they could use the name "Crossville, Tennessee, USA"  
as their timezone entry. That makes it easier for them to later do  
whatever they want.

    Patrik

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 14:42:37 -0500

Patrik Fältström wrote:

First of all, I think the publisher
of the timezone information should be able to decide on whatever
namespace they want to use. That is sort of the competition between
publishers, right?

well, it sort of sucks if you're trying to interpret an event with a
timezone and you don't have access to that publisher's information.

Secondly, I think they could use the
name "Crossville, Tennessee, USA" as their timezone entry. That makes
it easier for them to later do whatever they want.

if the publisher supports it.   but do we really expect publishers to
document and keep track of timezones for every city and town on earth?
and if we make timezones very fine-grained, how does this affect the
ability to resolve timezone information?

(granted, these days we have access to detailed map data for a good
percentage of the earth's land mass, so maybe it's not that
farfetched...)

Keith

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2009 22:10:30 +0200

On 3/30/09 9:42 PM, Keith Moore wrote:
> Patrik Fältström wrote:
>> First of all, I think the publisher of the timezone information 
>> should be able to decide on whatever namespace they want to use. That 
>> is sort of the competition between publishers, right?
>> Secondly, I think they could use the name "Crossville, Tennessee, 
>> USA" as their timezone entry. That makes it easier for them to later 
>> do whatever they want.
> document and keep track of timezones for every city and town on 
> earth?  and if we make timezones very fine-grained, how does this 
> affect the ability to resolve timezone information?
>
> percentage of the earth's land mass, so maybe it's not that farfetched...)

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2009 22:16:26 +0200

Sorry- let's try this again:

> timezone and you don't have access to that publisher's information.

Yes.  There needs to be some standard for availability.  I wouldn't want 
a plethora of these things anyway.  That just makes for the nightmare 
that in fact Cyrus is trying to recover from.  And so I would suggest 
setting the bar pretty high before making something a legitimate 
standard option.

> affect the ability to resolve timezone information?

There *is* an entrenched defacto standard here already.   The folks on 
the tz mailing list have a remarkable and under-appreciated track 
record.  The only reason we should want anything more than what there is 
today, is that some of us are uncomfortable with the succession planning 
of that team.  A URN was the best way I could think of to future proof 
us against the remote possibility of drastically bad happening.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 15:23:02 -0500

if the publisher supports it.   but do we really expect
publishers to
document and keep track of timezones for every city and town on earth?
and if we make timezones very fine-grained, how does this affect the
ability to resolve timezone information?

There *is* an entrenched defacto standard here already.   The folks on
the tz mailing list have a remarkable and under-appreciated track
record.  The only reason we should want anything more than what there
is today, is that some of us are uncomfortable with the succession
planning of that team.  A URN was the best way I could think of to
future proof us against the remote possibility of drastically bad
happening.

I honestly don't see how using URNs solves the problem.   If there's
nobody around to maintain the timezone databases, nobody who does a
good enough job to retain the trust of the software implementors of the
world, URN timezone names won't help.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Mar 2009 15:24:14 -0500

> embedding the city name in a timezone name is a bug - or at least

Hear hear!

 - People know the names of their local timezones.
 - People don't necessarily live in cities famous enough to appear in
   timezone names.
 - People don't necessarily know the timezones of other cities that are
   famous enough to appear in timezone names.
 - Some time zones don't relate to famous nearby cities (think of
   Indiana's time zones).
 - There are timezones which are not near any famous cities.

Yes, names like "PDT", "CST", ... are very country/language-specific, so
what?  I can learn the ones that are relevant to my activities.  And I
could find any others given a reasonable directory.

That's what we really need: a directory (registry!) of timezone name and
country/city name -> GMT offset + daylight savings rules.  Also to be
registered: coordinates defining the shape and size of each timezone.

Given such a directory/registry then URNs that encode city names, names
like "PDT", coordinates, and just plain GMT+-offset would all be useful.

Nico
--

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 30 Mar 2009 17:34:30 -0400

I think we(ietf) should:
- document/refer to existing practice which is widely used (i.e. Olson
db and any other)
- keep room for additional interesting work
- not try to invent a new scheme for timezones for now.

to me, the work is more about how we document/refer the existing
practice instead of going into new stuff. If external references are not
stable or consistent or ..., then we should look into owning it. if
there are ok, then we should only refer to it.

marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 30 Mar 2009 15:56:57 -0700

> and sometimes there is a dispute about which timezone applies to a

That could be OK.  The URN can be persistent even if the timezone
boundaries change at some point in time.  You just have to know the
period over which the URN is relevant, or more relevant the time point
at which the URN ceases to refer to a single timezone.

For example, a persistent URN could point to US/California timezone
information, for the period over which that area has consistent
timezone information.  If in 2013 California timezones splits into
Norcal and Socal, the US/California URN could point to a timezone
information resource that says "I end in 2013", and two new URNs could
be created to point to US/California/NorCal and US/California/SoCal.
The resource referenced by the first URN could even point to the two
new things once they're known.

I imagine that if an area is ever joined-- if the eastern bit of
Oregon ever rejoined Oregon -- we'd preserve the more granular
divisions anyway for as long as clients refer to them (forever).  And
in general we've seen that city names, though there are language
variants, are on the whole more stable than political divisions.  An
example, you might have both Europe/Cheb and Europe/Eger, a city with
two names but either more stable than referring to the controller of
the area of Sudetenland.   It's also OK if Europe/Wien or
Europe/Prague also refer to the same timezone definitions or different
ones.  S

Lisa

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 30 Mar 2009 18:09:53 -0500

There is a protocol defined in the IETF for resolving a location (lat/lng) to a URN.  Initially, this was defined so that you could find your local emergency services URI, but it would work quite well for TZs.  RFC 5222 (LoST).  However, a reverse mapping is not defined.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Timur Shemsedinov
Sent: Tuesday, 31 March 2009 1:34 AM
To: Eliot Lear
Cc: Apps Discuss
Subject: Re: supposing one would want to create a new URN space for timezones...

It's a good idea, I am in need of such URN for a long time.
But I must note that:
1. Timezones are independent from authority. Timezones regulation is in jurisdiction of local government of each territory.
2. Timezones are not stable from year to year, regulation can be changed by local government.
3. Timezones are related to Lat/Long coordinates, so we can resolve Lat/Long to timezone.
4. Daylight saving time should be considered too.
5. Which language do you prefer to name timezones? English / why not local languages?

I have following proposition:
1. Combine time, geographical coordinates and timezones in one URN
2. Develop mechanism for resolving Lat/Long to Timezone and backward, global time to local time and backward

... would this amount to a new NID, or is there someplace we should hang this?

1.  Olson
2.  IEEE
3.  Microsoft

The need for interoperability dictates one preferred method, which IMHO should be Olson.

Thoughts?

Eliot

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Mar 2009 05:03:55 +0200

> registered: coordinates defining the shape and size of each timezone.

I think we look at two different problems here, and Eliot suggested we  
should solve one of them (the first):

1. Have one way of globally naming the timezone entries, including  
past and future history, without injecting ourselves in the work the  
publishers of the TZ databases do, and definitely not injecting  
ourselves into the work the parties do that define the TZ entries.

2. Have a way to know, given city/lat/long/whatever, what TZ entry to  
use (over time).

I claim Eliot asked for a solution to the first, not the 2nd.

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Mar 2009 05:05:27 +0200

On 31 mar 2009, at 00.56, Lisa Dusseault wrote:

> The URN can be persistent even if the timezone

I would be MUCH more reliable to have the URN in an iCal object than,  
as often today, the TZ rule itself. Specifically for events in the  
future...

    Patrik

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 22:23:35 -0500

> new things once they're known.

yes you could do that.  and it's fine, as long as you don't issue a new
URN every time the definition of a timezone changes.  but you really
don't want to include any kind of precise geographic information in the
URN - no more precise than necessary.

for most of the world, an ISO 3166 country code should be sufficient to
define the timezone.  for those few countries large enough (in
longitude) to have multiple timezones, the country code + the accepted
abbreviations of the timezone names used in those countries should be
sufficient.  (beware: I18N considerations might lurk here)  there might
be a few special cases, like the 3 timezones in Indiana, but the special
cases can be expected to be relatively few.  similarly for the occasions
when it's necessary to deprecate a timezone name in favor of one or more
new ones.

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Mar 2009 05:32:12 +0200

> URN - no more precise than necessary.

Good point. I just took for granted that the URN was referring to a  
specific TZ "entry" (like "sweden") and what you got back was multiple  
TZ rules, each having a time interval when it is/was/will be valid. To  
know which one of the rules to use, you have to take the time of the  
event you want to do the calculations on, and select the portion of  
the returned data you are interested in.

    Patrik

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 22:48:59 -0500

Patrik Fältström wrote:
> I would be MUCH more reliable to have the URN in an iCal object than, as
> often today, the TZ rule itself. Specifically for events in the future...

with or without URN resolution to online versions of those iCalendar rules?

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Mar 2009 05:50:35 +0200

> with or without URN resolution to online versions of those iCalendar  

I always prefer with, if possible.

Given a unique name (for the series of rules), please give the rules  
back.

I see it being possible to do URN resolution of some kind as part of  
that, yes.

   Patrik

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 23:58:04 -0400

Thomson, Martin wrote:
> There is a protocol defined in the IETF for resolving a location
> (lat/lng) to a URN.  Initially, this was defined so that you could find
> your local emergency services URI, but it would work quite well for
> TZs.  RFC 5222 (LoST).  However, a reverse mapping is not defined.

separate problem.  let's get the basic URNs defined first, then the
resolution for those URNs.

note that global mapping lat/lng to tz names is a geopolitical mine
field.   we *really* do not want to get IETF, IANA, ISOC, or any I*
(except perhaps ISO or ITU :) ) into the business of deciding which
country a particular lat/lng pair falls into.  that's enough to start a
war, or at least get traffic to the resolution server banned in several
countries.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 30 Mar 2009 21:59:56 -0600

On Mar 30, 2009, at 9:03 PM, Patrik Fältström wrote:

> 2. Have a way to know, given city/lat/long/whatever, what TZ entry  
> to use (over time).

This is a hair-brain idea but .... LOST might be a protocol that was a  
good match to solve the second.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 23:59:11 -0400

> I always prefer with, if possible.

I'd love to see it.  But who would pay to run the servers?

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 31 Mar 2009 00:12:15 -0400

Hi Keith,

> I'd love to see it.  But who would pay to run the servers?

Well that is what we have been talking about in CalConnect. The key thing 
is who benefits from this - mostly the OS vendors who would be able to push 
timely updates to timezone data out without having to do a a full OS 
update/patch etc. Also anyone with a Calendaring & Scheduling service would 
likely offer something similar (and probably already do in some fashion).

A good comparison would be to NTP - most OS's come configured with an ntp 
server - several OS vendors run there own - I would expect to see the same 
thing happen for timezones. Admittedly this would be a "bigger" service 
than NTP.

This is somewhat reflected in the diagram in my apps area slides that show 
a tiered architecture for what we call "providers" - organizations offering 
a timezone service to "consumers". We would expect to see a few large 
organizations offering "tier 1" services, and then possibly many others 
offering a "tier 2" service more closely located with the actual "consumer" 
- these would be caches of the tier 1 servers.

-- 
Cyrus Daboo

---

From: Tony Finch <[email-masked]>
Date: Tue, 31 Mar 2009 12:42:30 +0100

On Mon, 30 Mar 2009, Keith Moore wrote:
>
> for those few countries large enough (in longitude) to have multiple
> timezones, the country code + the accepted abbreviations of the timezone
> names used in those countries should be sufficient.

That isn't sufficient in the USA because of Nevada and Indiana, nor in
Australia because they don't have standard abbreviated timezone names, nor
in China because of the unofficial Uighur timezone. You're going to have
to invent timezone names in many cases.

You also need more fine-grained timezones if your tz database goes back
any length of time. The history in the USA was very messy before the
federal government enforced uniform rules.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 10:47:23 -0400

Tony Finch wrote:

Agreed.  (I did say "there might be a few special cases"...)

For our purposes, I'm not sure it's necessary to create URNs for
timezones that no longer exist.  Other names could be created for these
by database publishers if they so chose.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 15:14:12 -0500

> This needs to be light weight.  If you want to localize, do it in your 

I'd like to agree, particularly as to localization.  But the key thing
is: besides a timezone name you also need the ability to convert a date
+ timestamp + timezone name into GMT/UTC +-offset.  I don't see how you
get to do that _interoperably_ without defining at least a timezone
_name_ registry.  E.g., my software says "US/Chicago" and yours says
US/Dallas" when they mean "US/Central" -- no interop.  If we never
exchange time data using timezone names but GMT/UTC +- offset then
there's no interop problem.

But if we do exchange time data using timezone names then what is to be
the meaning of a registered timezone name if the timezone itself is not
defined (or its definition referenced from) where the name is defined??

A timezone registry seems necessary, and it should at the very, very
least resolve timzone names to country name and, preferably, also the
relevant government agency/registrar and local timezone names (e.g.,
US/Chicago -> CST & CDT).  Yes, software publishers can just include a
version compiled from public sources -- we already do.

That's why "country/city" is so appealing for timezone naming: the
country that has the authority over the definition of a city's timezone
is clear from the name.  Of course, you'd better hope there aren't "twin
cities" with similar names but in different states/provinces/whatever
and with different timezones... :)  And that we all agree as to which
city names to use.  Also, this isn't what I call user-friendly (see my
earlier post), but at least it's feasible from a software development
p.o.v., so I think we're likely to get stuck with "country/city" in UIs
and GMT/UTC +- offset on the wire.  Which means: we don't need a
timezone URN.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 16:52:16 -0400

>> This needs to be light weight.  If you want to localize, do it in your 

To respond to Eliot's comment, I don't think we're going to tell
publishers what keys to use, or more generally, how to help users select
default timezones or timezones for events.  That's a UI concern. What we
might be able to do is to define standard timezone names to aid in
interoperability between different iCalendar implementations using data
supplied by different publishers.

> there's no interop problem.

Actually, there's still an interop problem when the timezone definition
changes between the time that the software is shipped and the time of
any events.  This actually happened for a large part of Australia
several years ago, and (despite what must have seemed like a lot of lead
time to the US Congress as of the last time they changed DST rules) it
seems to be happening in the US now.  (I'm currently sitting in a coffee
shop, and I've overheard a complaint about exactly this within the last
hour.)  The reason that iCalendar has support for timezone names is
because timezone definitions do sometimes change without much prior notice.

> defined (or its definition referenced from) where the name is defined??

Timezones are defined by political entities (mostly countries).  We
should define our timezone names in terms of those entities, and
standard abbreviations for those entities.   e.g. ISO 3166 country
codes.  Within a country, we should use accepted names or abbreviations
for timezones if those exist and if they're independent of
"daylight/summer time" conventions.   Where local conventions deviate
from national ones, we will need to decide on an ad-hoc basis.

The registry can be extensible, like the one we have for language codes.
 That way, if we miss some important timezones, others can request that
they be added.

> version compiled from public sources -- we already do.

I don't see any requirement that the standard timezone definitions map
from city name (or for that matter lat/lng) to standard timezone name.

(yes, such a registry would be useful, but I don't think IETF wants to
compile/maintain that registry any more than it wants to
compile/maintain its own registry of timezone periods and GMT offsets
for all of the timezones of the world.  we can leave that work to
others.  and as you point out, existing public sources already provide
that.)

> is clear from the name.  

let me make this really clear - country/city sucks for timezone naming
if you don't happen to live in or very near that city.  it's simply not
acceptable as a general scheme.  (it might be okay for the odd corner
cases.)

> Which means: we don't need a timezone URN.

since the premise is false, it doesn't support the conclusion.

I'll reserve judgment on whether URNs are suitable, but we need standard
timezone identifiers so that we can get interop between timezone
databases supplied by different publishers - at least for those "major"
timezones that are defined/maintained by governments (perhaps major
religious bodies also) and heavily used for scheduling future events.

that's not to say that such publishers have to change the names that
they're currently using.  but it would be nice if (and we could
recommend) that they support the ability to map from their own
definitions to IETF-standard timezone names (when equivalent names
exist).  and we could recommend that implementations of iCalendar and
other protocols include IETF-standard timezone names in event descriptions.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 16:27:03 -0500

> acceptable as a general scheme.  (it might be okay for the odd corner

Let me be clear too: I've said the same thing earlier and stand by that;
I in no way endorse the use of "country/city" as timezone names.

> since the premise is false, it doesn't support the conclusion.

Which part of the premise is wrong?  That we don't need timezone names
on the wire?  We don't -- send GMT +- offset or both, GMT +- offset and
localized time.  That "country/city" is a solution?  True, it's an
abobinable solution, but it is what has been deployed too often.

> religious bodies also) and heavily used for scheduling future events.

I agree, but for this you need a registry of accepted timezone names,
replete with links to actual authorities.

And note that it's entirely possible for politicians to create new
timezones and abandon old ones (again, think of State of Indiana-like
cases), which means that *any* registry is going to have a modicum of
interaction with those authorities.

IMO this sort of issue is best left to international standards
development organizations with national representation (think ISO), not
the IETF.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 18:11:06 -0400

> I in no way endorse the use of "country/city" as timezone names.

okay, maybe I misunderstood you.

> localized time.  

strongly disagree.  systems that do that are widely deployed, and
(predictably) break when TZ rules change.

> That "country/city" is a solution?  True, it's an abobinable solution, but it is what has been deployed too often.

certainly agree about the last part.

> replete with links to actual authorities.

I'd almost be fine with the names being UUIDs but I think that they'd be
more widely accepted if they were ASCII names that could be understood
by humans.  The ability to look at a name and have confidence that it's
the right name is pretty useful.

Heck, if it would help get consensus (and avoid arguing about local
names), I'd even accept the default (non summer-time) GMT offset as part
of the name for areas within countries that adopted the normal rules for
that country.  So US.W0005 for Eastern time, US.W0006 for Central, etc.
   (W for west of GMT, E for east of GMT).  Of course the convention
would not work for all cases but it might avoid some of the ratholes.

You could even have naming conventions for "does not use summer time"
like US.W0006-NST and avoid trying to name those regions in Indiana.

> development organizations with national representation (think ISO), not

I've made similar statements in the past.  If they're willing to take
this on, so much the better.  But I think the best way to make that
happen is for IETF to get things off to a good start, and then state a
willingness for ISO or whomever (who knows, maybe even ICAO, they have
as much interest in it as anybody) to take this over.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 17:23:02 -0500

> as much interest in it as anybody) to take this over.

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.

Cheers,

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 18:37:51 -0400

> I've decided to cc the currently listed IETF/ISO JTC1/SC6 liason,

biggest danger I see in having ISO do that is that (a) it would take too
long and (b) it would be done by people who are much more distant from
software development and UI concerns that IETF participants.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 17:33:18 -0500

> us against the remote possibility of drastically bad happening.

A timezone URN without a registry will not solve the problem -- every
publisher will be free to coin their own timezone URNs, leaving us with
the exact same problem that we have now (non-interoperable timezone
names, mismatches in publisher-provider timezone data, worrying about
"tz mailing list" "succession planning", and so on)...

...unless the new timezone URNs were all based on, say, {coordinates to
within some standard resolution, [season]}, in which case we could all
agree on timezone URNs, always (provided reasonably accurate position
information) but still we'd need publisher-provided TZ name->{TZ UTC/GMT
offset + DST info} resolution services.

Face it: we need a registry.  And: we need country authorities to
participate.  That means we need to ask ISO for a solution.  Q.E.D.  :)

Nico
--

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 31 Mar 2009 18:54:30 -0400

Hi Nicolas,

> participate.  That means we need to ask ISO for a solution.  Q.E.D.  :)

I disagree that authorities should have anything to do with this. We will 
never get governments etc all on board with this. As I recall Pete Resnick 
mentioned he had tried something like this in the past and failed.

The most important thing we need is a standard set of identifiers that are 
guaranteed to refer to the same timezone definitions (rules, offsets etc). 
That is the key thing needed for interoperability across calendaring and 
scheduling systems.

-- 
Cyrus Daboo

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 18:06:40 -0500

> mentioned he had tried something like this in the past and failed.

ISO does get things done.  Slowly, perhaps, but we (the IETF) are not
necessarily much faster.  I realize that Pete Resnick is one of the
liasons to the ISO, but ISTM that Allison Mankin is the relevant liason
here (please correct me if I'm wrong!).  If Peter and Allison say "forget
asking the ISO," fine.

> guaranteed to refer to the same timezone definitions (rules, offsets etc). 

Great.  How does one "refer to the same timezone definitions"?  Where
are those?  I don't see how to escape the need for a registry.  Sorry.

> That is the key thing needed for interoperability across calendaring and 

I agree with this.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 31 Mar 2009 20:34:29 -0400

Hi Nicolas,

--On March 31, 2009 6:06:40 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> The most important thing we need is a standard set of identifiers that
>> are  guaranteed to refer to the same timezone definitions (rules,
>> offsets etc).
>

What is being proposed is a registry and a service. The registry defines 
the standard set of names that allow "consumers" to interoperate. 
"consumers" get matching timezone definitions by asking their "provider" 
(offering a timezone service) to return the data to them. "providers" get 
their data from one or more "publishers", optionally adding useful 
meta-data (who the publisher is, what version of data they have, geo 
information, whatever). The service takes care of handling updates to 
changes in the data. "publishers" get their data in whatever way is 
appropriate for them. In the case of an Olson style service, that would 
involve "contributors" spotting local changes to timezone definitions and 
posting those back to the publisher to incorporate into their data.

As Elliot has noted on several occasions, the way Olson works right now is 
pretty good. Some things need to be tweaked: guaranteed longevity of 
service, digital signatures on the data etc.

The goal here is not to put the data into the registry, just the names. 
Given that this is an internet-wide service, a typical registrar (e.g. 
IANA) is not going to be able to scale to the demand from "consumers" 
(which will potentially be every desktop and mobile device and more). The 
"providers" are the ones who offer a scalable solution using whatever 
operational model makes sense for them, but using the standard timezone 
service apis we define.

Really I see the only issue as being one of whether the timezone 
identifiers are specific to publishers or not. If they are, then someone 
(presumably the "providers") will have to maintain some kind of mapping to 
allow some degree of interoperability.

-- 
Cyrus Daboo

---

From: SJ Kissane <[email-masked]>
Date: Wed, 1 Apr 2009 14:48:16 +1100

Hi all

Wow this thread is long, I don't have time to read it all, but let me add my
own two cents.

Unicode CLDR (http://cldr.unicode.org/) already defines unique identifiers
for timezones,
which are the Olson names, save that as I understand, they only use the
first name ever
defined, so if the name ever changes in Olson, they stick to the original
name.
(see UTS#35 section 5.9.2 --
http://www.unicode.org/reports/tr35/#Timezone_Names)

It defines timezone names in multiple languages, mapping to pre-existing
vendor
standards (i.e. Windows) -- I think it would be silly for IETF to reinvent
the wheel
when the Unicode consortium are doing so much already in this area.

The point of a URN is to have a unique identifier, not every possible
identifier you'd want to use.
So I'd say, use the CLDR identifier in the URN -- and then use a database
like CLDR
to map those URN values to names in various languages to display to user,
or to map to vendor standards like Microsoft Windows, or so on.

Simon Kissane

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 01:18:51 -0400

Nicolas Williams wrote:

non sequitor.  :)

I agree that, in the long term, you want to get countries to publish
their timezone definitions.  I also think it's useful to have them
define new timezone names when needed, and to maintain the links
between their names and the published definitions.  (nothing stops
existing publishers from proofreading and fixing such definitions as a
value-added service.)

But IMHO these names are less likely to have the right semantics if
they're initially defined by ISO, than if they're initially defined by
an IETF WG composed of people with experience in developing iCalendar
implementations.  Remember, the challenge is to get the naming right,
not the definitions themselves.  Getting the naming right means picking
semantics for the names that maximizes the potential for
interoperability, and picking a form for the names that encourages the
right semantics.

Keith