Timezone translations

Mark Davis mark.davis at jtcsv.com
Mon Jun 6 00:23:17 UTC 2005


> I'm sorry, but I'm not going to do all that, especially when you've
> told me in advance that the only terms I would use for UK non-summer
> time will be rejected. What's the point?

The reason why we have such cautions is that we have found that many people
don't provide enough information in the reports for us to do anything
reasonable with it -- and often don't respond to follow-up questions, so we
try to provide enough background information so that that doesn't happen.
Since you are not interested in filing the bug, I filed one with the
information you provided, at
http://www.jtcsv.com/cgibin/locale-bugs?findid=738

Our goal is to match customary usage in the countries covered, but I was
trying to give you a sense of the options that we have. If "GMT" means
something ambiguous, then we have to find a way to resolve that ambiguity.
As I mentioned, one alternative is that in the UK locale (en_GM), "GMT"
means Europe/London, whereas in other English-speaking locales it means
Etc/GMT. That would let your fellow in the traffic jam see what he expects.
But there are downsides to that approach.

One thought I had while reading this discussion is that we may need to
explore trying to refine our recommendations for usage to allow us to relax
the roundtripping requirement for cases where the ambiguity is probably
acceptable. The datetime format strings used to provide a pattern for
formatting, with the following letters being used:

z:      for short wall (generic) (eg PT)
zz:     for long wall (eg Pacific Time)
zzz:    for the short specific (eg PST)
zzzz:   for the full specific (eg Pacific Standard Time).
Z:      for GMT format (eg GMT-08:00)
ZZ:     for  RFC 822 format (eg -0800)

Thus where the purpose is to pick a tzid from a menu or in
formatted/parseable strings -- and especially for recurring meetings -- we
would recommend using the generic form, and keep the requirement for
uniqueness of names within a language. On the other hand, for formatting a
specific time with the specific standard/daylight (winter/summer) strings,
allow collisions in the translations *if* the results would be the same in
modern time. Thus as long as "GMT" meant a constant GTM+00:00, it would be
ok if there was a collision in translated names between Europe/London and
Etc/GMT (or between Africa/Casablanca and Etc/GMT, etc.).

In the end, it is up to the CLDR committee to try to come up with a
solution, but suggestions are welcome.

> Finally, I'll repeat the question from my first mail about this, which
> I forgot to add to my last mail: where did the current data for
> Europe/London in the en_timezones.html come from?

I would have to wade back through all the checkins to see where it came
from. Frankly, since it looks like it is wrong anyway, it is not a
particularly good use of time.

‎Mark

----- Original Message ----- 
From: "Peter Ilieve" <peter at aldie.co.uk>
To: <tz at lecserver.nci.nih.gov>
Sent: Sunday, June 05, 2005 04:21
Subject: Re: Timezone translations


> On 5 Jun 2005, at 00:04, Mark Davis wrote:
>
> > In this particular case, however, it is unclear what we should do;
> > that's
> > why I tried to spell out the issues. It would be very easy for us
> > to change
> > the summer time to British Summer Time, but for the winter time
> > there is a
> > problem, because of the ambiguity of the use of the term "GMT".
>
> But lots of the abbreviations are ambiguous. When I first got involved
> with this sort of stuff, back in the days of 4.1c bsd or so, I remember
> the surprise of discovering Bering Straits Time for example. It's hard
> to avoid this ambiguity when you've only got three letters, and one
> of them is almost bound to be T.
>
> It's the concept of "can't use the long name Greenwich Mean Time or the
> abbreviation GMT" (from your previous mail) that I'm struggling to
> understand. I've been on the timezone mailing list for a long time,
> and I like to think I've contributed something towards documenting the
> convoluted history of UK summer time changes. During that time I've seen
> Arthur Olson and Paul Eggert work to try to make sense of the chaotic
> human messiness of timezone naming, and try and catch up with the
> capricious changes that politicians make to the clocks. There's
> no notion of "can't" in this. If someone pops up and produces credible
> evidence that some group of people call their timzeone XYZ, then XYZ
> goes in the database. It reflects what people use in their everyday
> lives.
>
> The CLDR doesn't seem to be like that. Your talk of roundtripping,
> parsing and so on implies some higher purpose. I wrote higher as
> the result is that I "can't" call my local winter time by the only
> name by which I have known it ever since I can remember.
>
> Take the famous man on the Clapham omnibus, now armed with a laptop
> and cadging Internet access from a nearby insecure WiFi access point
> while his bus is stuck in the traffic. He wants the dates in his emails
> to look right, and that means having GMT in the winter. If you tell
> him that he can't have that because some bunch of programmers who he's
> never heard of say it will upset the internal workings of some software
> he's never heard of either he is unlikely to be impressed. If you ask
> him if he would mind having "GMT (UK)" instead to fix this he is likely
> to give a dusty answer.
>
> > Here is the problem. [calendar scheduling details snipped]
>
> That is indeed a problem. I don't have an answer to it. I suspect the
> answer will involve using UTC times and a timezone name like Europe/
> London,
> with the Europe/London taken from the preferences set for the particular
> application or from the user's default settings.
>
> Going back to your suggestion that I file a bug report, I visited that
> URL and it reminded me why I didn't try and file a bug before. It
> has a warning that I must read the Data Formats and Filing Bug Reports
> before submitting. OK, I thought, maybe I can skip the data formats
> one and just read the one about filing, but no, that page not only
> repeats the instruction to read the data formats page but adds more
> instructions to consult the comparison and by-type charts.
>
> I'm sorry, but I'm not going to do all that, especially when you've
> told me in advance that the only terms I would use for UK non-summer
> time will be rejected. What's the point?
>
> Finally, I'll repeat the question from my first mail about this, which
> I forgot to add to my last mail: where did the current data for
> Europe/London in the en_timezones.html come from?
>
>
>          Peter Ilieve        peter at aldie.co.uk
>
>
>





More information about the tz mailing list