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

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 11:36:49 +0200

On 3/31/09 10:52 PM, Keith Moore wrote:
> 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.
>    

This assumes two things: first that there is a problem that requires 
fixing.  Why do you believe that there is?  The Olson database for over 
two decades.  It's free and it's well managed.

Second, if there is a need for standard timezone names, who is going to 
manage the mapping between them and what the publishers put out?  I see 
no reason why anyone would want to do the job unless there is a REAL 
problem.

Here is the problem I want to solve: a standard form for a name that 
includes publisher and the pubisher's (preferrably human readable) index 
for a given location.  Second, if we feel we need to approve of the use 
of one publisher, we say that separately, and allow for the possibility 
that it might change in the future.

> 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.
>    

Why?  Why should we deal with the fact that all of western Europe is in 
one timezone (CE[S]T) while Indiana has counties that have distinct 
timezones, especially when others are already doing a good job at it?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 13:01:45 +0200

On 4/1/09 1:06 AM, Nicolas Williams wrote:
> 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.
>    

There is a registry.  It's existed for quite a long time, Nico.  In fact 
there are several (which is the problem).  Creating ANOTHER one and 
creating alot more work will not make things better, and will serve to 
only annoy those who currently do a very good job.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 09:27:43 -0400

> no reason why anyone would want to do the job unless there is a REAL

The problem that I think exists is that event descriptions now must, as
a practical matter, include reasonably complete descriptions of the
event's timezone.  And if the timezone definition changes between the
time the event description is created and the event itself, the event
description becomes wrong.

Really, what's being done now is only marginally better than sending GMT
offset (and even then only for recurring events that cross a "summer
time" change boundary), because the indication of the timezone that is
sent is neither portable between iCalendar implementations nor is there
any way of mapping it to a current timezone definition.

> that it might change in the future.

I think it harms interoperability for the name to be specific to a
particular publisher, and I don't think IETF wants to be in the position
of naming any specific publisher.

> timezones, especially when others are already doing a good job at it?

Others are not doing a good job at naming timezones.  They're doing a
really poor job of it, IMHO, by encouraging use of cities as timezone names.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 09:30:00 -0400

> only annoy those who currently do a very good job.

They're doing a very good job of describing timezones and their changes
over time.  That's not the same thing as doing a good job at naming
timezones in such a way that those names can be used by multiple
publishers, or multiple software vendors using a variety of publishers.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 01 Apr 2009 09:53:38 -0400

Hi Keith,

> any way of mapping it to a current timezone definition.

So technically there should not be a problem with timezones in iCalendar 
because iCalendar requires that timezones be passed by value - i.e. the 
VTIMEZONE component included in the VCALENDAR object that references a 
timezone. If implementations strictly interpreted that behavior they would 
use the VTIMEZONEs supplied in an iCalendar object to calculate UTC and 
Organizer and Attendees would arrive at the same value. The problem comes 
in that each implementation typically has its own timezone database and 
they prefer to throw away incoming timezones in favor of their own 
definitions. Since those databases can get out of sync (or may be 
completely different and require some form of fuzzy matching between 
timezone ids), Organizers and Attendees can end up with different UTC times 
for the same event - bad news!

So, again, one of the key reasons to do this work is to recognize the fact 
that implementations are really treating timezone exchanges as "by 
reference" rather than "by value" (i.e. they discard the supplied VTIMEZONE 
data in favor of their own that matches the TZID). In order for that to 
work there must be agreement on the timezone identifiers and a standard 
timezone service that allows clients to keep their databases up to date via 
regular updates. If we do these two things we solve the biggest problem 
that exists today.

-- 
Cyrus Daboo

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2009 15:59:19 +0100

On Tue, 31 Mar 2009, Keith Moore wrote:
>
> 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.

Australia's DST rules vary between the states.

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

That would exclude informal timezones.

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: Wed, 01 Apr 2009 11:08:24 -0400

Tony Finch wrote:

I don't think it's possible to make a naming scheme that's so general
that it covers every case.  but a general naming scheme might reduce
the number of things that people want to argue about.

Still, this might mean that rather than having, say, an IETF WG try to
define names for every major timezone, it makes more sense to (a) set
up a registry and a review process, (b) make some recommendations for
the format of timezone names that serve as guidelines to the reviewers,
and (c) invite interested parties to submit registrations.

Keith

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2009 16:12:25 +0100

On Wed, 1 Apr 2009, Keith Moore wrote:
> define names for every major timezone, it makes more sense to (a) set up
> a registry and a review process, (b) make some recommendations for the
> format of timezone names that serve as guidelines to the reviewers, and
> (c) invite interested parties to submit registrations.

You just described exactly what Olson's tz list does.

Tony.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 17:43:58 +0200

> You just described exactly what Olson's tz list does.

Precisely so.  The only issue is this: what is the succession plan for 
the distribution?  What happens on the off chance it implodes?  And 
perhaps Cyrus and Barry are implicitly correct in the draft that we 
should make this tomorrow's problem, and not today's if this 
conversation is any indicator.

Eliot

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2009 17:16:14 +0100

On Wed, 1 Apr 2009, Eliot Lear wrote:
> Precisely so.  The only issue is this: what is the succession plan for the
> distribution?  What happens on the off chance it implodes?  And perhaps Cyrus
> and Barry are implicitly correct in the draft that we should make this
> tomorrow's problem, and not today's if this conversation is any indicator.

Allowing multiple publishers allows for forking Olson's tz project or
resurrecting it, as well as making space for the CLDR and commercial
publishers and so on. It's a lightweight and general mechanism that
matches the current state of play.

A lot of the arguments in this conversation would go away if we had a
location -> tz lookup service, especially if that service can cope with
multiple publishers' tz names. Yes this is just moving the problem but I
think it is being moved to the right place.

Or to be more exact, this is where the problem already lies, and the
service doesn't exist because it's a hard problem. This should be a
warning that redrawing the boundaries is likely to make a standards
effort fail, by making it unnecessarily hard to solve the easy parts.

Tony.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 11:56:08 -0500

On Wed, Apr 01, 2009 at 01:18:51AM -0400, Keith Moore wrote:
> <font face="courier">Nicolas Williams wrote:</font><br>
> <blockquote cite="mid:[email-masked]" type="cite">
>   <pre wrap=""><font face="courier">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.  :)
> </font></pre>
> </blockquote>
> non sequitor.&nbsp; :)<br>

Anything involving national politics and international standards best
belongs in the ISO.  Indeed, it does not follow that the IETF cannot do
anything in this space, but it does seem likely to create friction --
thus we need at least a path to ISO involvement.

My proposal then (I hinted at this earlier) is to create an IANA
registry, seed it from existing sources, and open the registry to
submitters named by the relevant IETF-ISO liasons.  That way we can a)
move fast, b) let country authorities take over if they care to, c)
allow existing timezone data maintainers to continue doing that until
(b) happens on a country by country basis.

> I agree that, in the long term, you want to get countries to publish
> their timezone definitions.&nbsp; 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.&nbsp; (nothing stops
> existing publishers from proofreading and fixing such definitions as a
> value-added service.)<br>

Indeed, nothing does.  In fact, we all do -- they ship with operating
systems and various applications and can be found elsewhere as well.

> 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.&nbsp; Remember, the challenge is to get the naming right,
> not the definitions themselves.&nbsp; 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.<br>

I've not problem with the above -- we're more or less proposing the same
sort of thing: an IETF-created and seeded IANA registry with a political
safety valve to hand things off to ISO member countries as they step up
to do the maintenance work.

BTW, we don't need a service if publishers will just publish copies of
the IANA registry.  There's no need to create a global timezone data
distribution service infrastructure.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 19:22:25 +0200

> think it is being moved to the right place.

What is the difference between what you are suggesting here and the DHCP 
timezone option?

Eliot

---

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

Tony Finch wrote:

last I knew, Olson's tz list did not have a distinguished, reasonable,
publisher-independent name for each timezone.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 13:28:29 -0400

Tony Finch wrote:

excellent idea.  but if you want to have multiple publishers, you need
a set of timezone names that is independent of publisher if you want
interoperability.

A lot of the arguments in this conversation would go away if we had a
location -> tz lookup service, especially if that service can cope with
multiple publishers' tz names.

no they would not.  that's an entirely separate problem.

Or to be more exact, this is where the problem already lies, and the
service doesn't exist because it's a hard problem.

to me it looks like a suggestion for trying to turn a relatively easy
problem into a difficult one.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 13:29:53 -0400

Eliot Lear wrote:

location ->  tz lookup service, especially if that service can cope
with

multiple publishers' tz names. Yes this is just moving the problem but
I

What is the difference between what you are suggesting here and the
DHCP timezone option?

sigh.  a DHCP timezone option, like a lot of other DHCP options, makes
no sense - because the timezone you are in and where you are attached
to the network are not inherently related.

and anyway, what would be the use of a DHCP timezone option without a
standard set of publisher independent timezone names?

Keith

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2009 18:31:46 +0100

> What is the difference between what you are suggesting here and the DHCP

We need a mechanism for looking up the tz used by an arbitrary place.
We're talking about calendaring and scheduling, not host configuration.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 13:38:14 -0400

> We need a mechanism for looking up the tz used by an arbitrary place.

*why* do we need such a mechanism?  do you think that people don't know
what timezone they're using when they schedule a meeting?  do you think
that people always schedule meetings at their current lat/long
locations?  do you think that people know the lat/longs of locations at
places where they schedule meetings?

I'm not saying such a mechanism isn't useful, but it's not a solution to
the problem we're trying to solve in this discussion.

---

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

belongs in the ISO.

...or some similar international organization with close ties to
governments.  which one is beyond my claimed expertise.

(though I still wonder if ICAO hasn't solved this problem already)

Indeed, it does not follow that the IETF cannot do
anything in this space, but it does seem likely to create friction --
thus we need at least a path to ISO involvement.

I'm fine with having a path to involvement by ISO or a similar
organization.

I'd instead have submitters be anybody and have the reviewers be named
(or approved) by relevant liasons, or perhaps by some IETF appointees
and some ISO (or whomever) appointees.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 19:53:22 +0200

> We're talking about calendaring and scheduling, not host configuration.

They're related.  It depends on whether you want to look up tz of your 
host or of others.  If it's your host, DHCP options do that just fine.  
If it's of others, or if it's yours sometime other than "now", then you 
need a lookup as you describe.  And while that problem perhaps has been 
solved, it's not simple code.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Apr 2009 19:56:27 +0200

On first blush, I think what you're suggesting might go a long way in 
the right direction.  This would require no new documents from the IETF 
side, and we could just reference the Unicode CLDR.

---

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

On Wed, Apr 01, 2009 at 02:48:16PM +1100, SJ Kissane wrote:
> 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)

Oh, good point!

> 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.

Indeed.

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Apr 2009 19:11:50 +0100

On Wed, 1 Apr 2009, Keith Moore wrote:
> what timezone they're using when they schedule a meeting?

Yes, when the meeting is in a place that they are not familiar with, or
when tz boundaries change.

> do you think that people know the lat/longs of locations at

No, I mean places as in names of towns, not co-ordinates.

> the problem we're trying to solve in this discussion.

You are right, it's a different problem. However, if you have a mechanism
for getting the tz data for a place then you no longer need to expose the
name of the tz data - that becomes internal to the data provider. This
means tz naming is no longer crucial for interoperability, and you no
longer have to worry about tz stability over time because the lookup is
more dynamic.

However a simpler (smaller) solution to the naming problem is to make it
easy to obtain the mapping between names from different publishers. The
CLDR already does this, so I expect it can be part of the service proposed
by Cyrus.

Tony.

---

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

a database mapping place names to standard, distinguished timezone
names would clearly be useful.

You are right, it's a different problem. However, if you have a mechanism
for getting the tz data for a place then you no longer need to expose the
name of the tz data - that becomes internal to the data provider.

disagree.  you still have the problem that timezone rules change,
sometimes on relatively short notice.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 01 Apr 2009 15:51:54 -0400

Hi Keith,

--On April 1, 2009 3:45:30 PM -0400 Keith Moore <[email-masked]> wrote:

> a database mapping place names to standard, distinguished timezone names
> would clearly be useful.

As I noted before there are already sites offering services like this, e.g. 
<http://www.geonames.org>. Encouraging a standard protocol to retrieve that 
information would be great - LoST being one mentioned previously in this 
thread.

-- 
Cyrus Daboo

---

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

>> doing so much already in this area.

I've generally found the Olson names to be very poorly chosen.  Many of
them are based on city names, which distances them from the reality that
in most cases these conventions are dictated by national or local
governments.

So I think, unfortunately, the Unicode work is not going to be acceptable.

Keith

---

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

Cyrus Daboo wrote:
> As I noted before there are already sites offering services like this,
> e.g. <http://www.geonames.org>. Encouraging a standard protocol to
> retrieve that information would be great - LoST being one mentioned
> previously in this thread.

and of course it would help if there were standard timezone names to map to.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 15:32:22 -0500

> That would exclude informal timezones.

You're jumping to conclusions.  I didn't say anything about not having a
private use sub-namespace.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 15:42:34 -0500

On Mon, Mar 30, 2009 at 03:56:57PM -0700, Lisa Dusseault wrote:
> On Mon, Mar 30, 2009 at 9:30 AM, Keith Moore <[email-masked]> wrote:
> > 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.
> 
> 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.

It doesn't matter what the canonical name of a timezone is IF there are
useful aliases (for query syntax), meaningful display syntax for
canonical names, and a usable canonicalization mechanism.

My timezone could be named by a UUID, or by <location>+<version> or
<location>+<date-it-went-into-effect>, and so on.  A UUID would be
utterly useless for humans.  A canonical name form with a display form
like <country>[/<state-or-province>][/<city>] would be fine, even if
obnoxious, provided I could reliably enter something like "PDT".

The CLDR timezone definitions actually provide for aliases.  So it seems
like a useful candidate.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 17:28:05 -0400

> canonical names, and a usable canonicalization mechanism.

Pretty much agree.  The main value in having it be meaningful to humans
is as a sanity check.  e.g. if timezone names were of the form
"TZ."[-+]{HHMM}"."{ISO3166}["."{modifier}] and you found some software
that mapped a location in Oregon to TZ.-0500.CA, you'd know at a glance
that something were wrong.  Correspondingly you could scan a timezone
database with mappings from publisher zone names to standard zone names,
and more or less be able to tell at a glance whether the mappings were
reasonable.

If the timezone IDs were say UUIDs we wouldn't have that kind of sanity
check, and transcription errors would be more likely.  Also I think it
would invite publishers to create their own UUIDs rather than map to
standard ones.

But again, for the problem at hand I don't think we even care about
aliases, query syntax, display syntax, or canonicalization.  All we care
about is being able to name timezones in such a way that different
publishers can treat our names as distinguished aliases for their
existing definitions, and such that software can export those aliases in
event descriptions.  For the most part, users don't have to see these
things.

> The CLDR timezone definitions actually provide for aliases.  So it seems

The definitions are probably as good as any, since they're derived form
the Olsen database.  But we're not proposing to standardize the
definitions, just the names.  And the CLDR names (and the
canonicalization algorithm) are totally screwed up for use in event
descriptions.  So, apparently, are everyone else's names.  That's why
we're having this discussion.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 16:37:30 -0500

On Wed, Apr 01, 2009 at 05:28:05PM -0400, Keith Moore wrote:
>                               And the CLDR names (and the
> descriptions.

Er, but the CLDR does provide for aliases.  So, how's it broken?  (I've
not looked at the data, no...)

---

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

> not looked at the data, no...)

I expect that the CLDR database of mappings between GMT and the timezone
is good, since it's derived from the Olsen tz list database.

Unfortunately, the distinguished names in CLDR are poorly chosen.

Having an alias feature is good, but there needs to be some way to
distinguish the standard name for a timezone from other aliases for that
timezone.

(This might be accomplished simply by making standard timezone
identifiers be sufficiently different (and ugly) that nobody would
confuse them for an alias of any other kind. )

Keith

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Apr 2009 11:27:13 +0100

On Wed, 1 Apr 2009, Keith Moore wrote:
>
> > However, if you have a mechanism for getting the tz data for a place
> > then you no longer need to expose the name of the tz data - that
> > becomes internal to the data provider.
>
> disagree.  you still have the problem that timezone rules change, sometimes on
> relatively short notice.

If the lookup from place to tz rules is dynamic then *all* problems with
tz instability go away.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2009 07:30:28 -0400

> If the lookup from place to tz rules is dynamic then *all* problems with

only if you maintain tz rules for regions with extremely fine
granularity (say at the level of postal codes in the US).

and even then you have the problem of what to do when there's a dispute
about which timezone applies to a particular region.

Keith

---

From: Dan Winship <[email-masked]>
Date: Thu, 02 Apr 2009 11:39:47 -0400

Keith Moore wrote:
> For the most part, users don't have to see these things.

At some point, the user's computer needs to figure out what time zone it
is in, and likewise for the user's calendar app. If there is not a
standard protocol for doing this automatically somehow, then the user is
going to need to see the list of timezones, and somehow be able to pick
the correct one. Olsen mostly works OK for this for the easy cases, but
is pretty awful for the tricky cases; no one except Olsen himself is
going to know which city in Indiana happens to have the same history of
Eastern time vs Central time as the city that they live in.

And for labeling events that are entirely in the present and future, it
doesn't even matter whether they pick the one that happens to have the
right offsets in the past. And even if they do pick the right one,
there's no guarantee that it will *continue* to be the right one in the
future. Given the constant splitting of timezones in Indiana, a user
could send out a meeting request to his colleagues for a once-a-week
recurring meeting at 10am Thursday in America/Indiana/Indianapolis time,
only to have his county switch timezones away from Indianapolis a few
months later, forcing him to send out an updated meeting request
changing the future instances to the newly-created timezone. (In fact,
if *Indianapolis* decides to switch timezones and the user's county
decides to not switch, the user *still* needs to send out an updated
meeting request, or else the time of the existing appointments will
automatically change to match Indianapolis.)

There are situations where it's important to have information about the
history of GMT offsets in a particular location. But most of the time,
you just want to know which GMT offset (or pattern of summer/winter
offsets) applies *now*. Splitting this into two separate things (ie,
having standard identifiers for the things that ordinary people think of
as "time zones": "Eastern Time", "Moscow Time", "Western Australia
Time", etc; and a then a separate set of standard identifiers for
specifying historical change data like "the same pattern of using
Eastern/Central Time as Indianapolis") rather than merging them into a
single identifier (Olsen timezones) will probably make things much
easier for users to deal with, and may make the spec simpler as well...

-- Dan

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 10:54:48 -0500

On Thu, Apr 02, 2009 at 11:39:47AM -0400, Dan Winship wrote:
> the correct one.

We've been discussing several very different but related problems:

1) how to represent timezones in application protocol data;
2) how to represent timezones in UIs;
3) how to find one's current timezone.

The CLDR is sufficient for (1) because if provides for canonical
timezone names.

The CLDR is sufficient for (2) because it allows for alternative,
user-friendly and even localized timezone names.

To the extent that any of the canonical name or aliases of a user's
current timezone are familiar to the user, then the CLDR provides one
solution to (3).  But not every user will know any of the names for
their current timezone.

For networks where physical location and IP address are highly
correlated then a DHCP option should suffice for solving (3).  But not
every IP address is easily mapped to a physical location with sufficient
resolution, and not every DHCP server is going to offer this feature.

For any node that has a receiver for GPS, WWV or the like, then a
location->timezone service would be great.  But not every node has such
a device.

I don't see how we can solve (3) with just one solution.  We'll need all
of the above.

> And for labeling events that are entirely in the present and future, it
                                                               ^^^^^^

Good point!  A date + timestamp + timezone can be written long before a
timezone change.  We can't prevent all failure modes resulting from
timezone changes.

Nico
--

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 02 Apr 2009 12:18:38 -0400

Hi Nicolas,

> user-friendly and even localized timezone names.

Right now most UIs provide some sort of map-based graphical timezone picker 
- i.e. a "fuzzy" location to timezone service.

> resolution, and not every DHCP server is going to offer this feature.

Such a DHCP option already exists: RFC4833. That allows use of POSIX TZ 
strings and Olson strings.

> timezone change.  We can't prevent all failure modes resulting from

A CalConnect document discusses many of the problems that arose from the US 
shift in 2007: 
<http://www.calconnect.org/pubdocs/CD0707%20CalConnect%20EDST%20Reflections%20and%20Recommendations.pdf>.

In an ideal world we would like clients to be able to detect that a 
timezone has changed in some way and automatically figure out what events 
need to be updated, or at least flagged to users as potentially needing to 
be re-scheduled. This is a complex task. One of the things we would like a 
timezone service to do is actually do the hard part of figuring out what 
UTC time ranges in the future are impacted by a timezone change, and return 
that list to the client which can then figure out which events fall in 
those ranges.

-- 
Cyrus Daboo

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 11:26:55 -0500

> that list to the client which can then figure out which events fall in 

You can't resolve all such problems automatically.  If I schedule an
event for 2010-04-01 10:00:00 EDT and Congress changes EDT to start on
the following Sunday then what happens?  Should the schedule change to
be at 9AM EST, or should the schedule be updated to show 2010-04-01
10:00:00 EST?  I'd say that depends at least on the type of the event
(e.g., for a wake-up alarm -> change the timezone, for a meeting ->
change the time and the timezone).  But can that determination be made
automatically in all cases?  I doubt it.  In most cases changing the
time and timezone of the event will do though.

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Apr 2009 17:58:53 +0100

> about which timezone applies to a particular region.

A very good point, thanks.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2009 17:04:42 -0400

> The CLDR is sufficient for (1) because if provides for canonical

false, for reasons stated earlier.

> user-friendly and even localized timezone names.

depends on the UI.

> timezone change.  We can't prevent all failure modes resulting from

true.  there are many sources of potential error, e.g.: users or
software can select the wrong timezone, the timezone originally
associated with an event can change boundaries, the timezone might
change but the database used by an event recipient fail to be updated.

the best we can hope to do is to minimize the potential for failures.

Keith

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 16:20:58 -0500

> false, for reasons stated earlier.

IIRC you had complains about the form of the canonical name chosen for
CLDR, but I don't care because (1) is about what appears on the wire
(and in document meta-data) and I don't care what form that takes.

> > user-friendly and even localized timezone names.

Yes, but that's not CLDR's fault.

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2009 19:31:23 -0400

> (and in document meta-data) and I don't care what form that takes.

I guess we're just going to agree to disagree here.

---

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

Nicolas Williams wrote:

> the following Sunday then what happens?

if EDT appears as a timezone in an event description, it's a bug in the
software that generated that event description.

> Should the schedule change to be at 9AM EST, or should the schedule be updated to show 2010-04-01
> 10:00:00 EST? 

the right thing is for the user agent that generates the event
description to not offer EDT as an option.

what should the receiving system do?  probably flag the event as
malformed because it's ambiguous, and let the user try to resolve the
ambiguity.

Keith

---

From: Tony Finch <[email-masked]>
Date: Fri, 3 Apr 2009 14:11:00 +0100

On Thu, 2 Apr 2009, Nicolas Williams wrote:
>
> You can't resolve all such problems automatically.

I believe the only cases that need manual assistance are:

* Events whose scheduling depends on the DST transition itself, i.e. those
occurring in the early hours of the affected Sundays.

* Events that occur in multipls places (e.g. transatlantic flights or
conference calls) where the tz change does not affect all the places.

Other events should not need to be modified. If they do need to be
modified then you've fixed the events' tz data too early.

Tony.