Re: [tz] Belarus is listed in MSK timezone
How can we even hope to achieve time zone abbreviations that follow what people use on the ground if some places don't use abbreviations at all? We also impose English abbreviations, when English might not be spoken in the region at all. IIRC, doesn't French Canada have abbreviations like HNE instead of EST? Personally, I'd rather see abbreviations removed entirely. If folks want them for display, they should probably get them from CLDR, where the can be properly localized. All we really need in tzdb is a flag to identify whether to use a standard-time or daylight-time version of the abbreviation. Am I wrong? I suppose some of the historical values like those used in "war time" wouldn't be in cldr, but couldn't those be moved to a separate file? ________________________________ From: Alan Barrett<mailto:apb@cequrux.com> Sent: 4/2/2015 12:57 PM To: tz@iana.org<mailto:tz@iana.org> Subject: Re: [tz] Belarus is listed in MSK timezone On Wed, 01 Apr 2015, Dzmitry Kazimirchyk wrote:
The main problem here is with MSK being both historically and nowadays widely known as "Moscow time" and absolutely zero public awareness of the fact that now it can also mean "Minsk time" in addition to lack of any official sources explaining that.
What time zone abbreviation do people, news media, or official government sources in Belarus use to refer to their time zone? If there is a simple answer, than that's what should go into the tz database. If people on the ground disagree about the abreviation, then we can conduct some sort of popularity survey, as we did with Australia and the EST versus AEST question. If people on the ground don't use any abbreviation, then I suppose the tz project has to guess or invent something. --apb (Alan Barrett)
On 03/04/15 08:22, Matt Johnson wrote:
How can we even hope to achieve time zone abbreviations that follow what people use on the ground if some places don't use abbreviations at all?
While on one hand the bulk of the current rules are well established, some edge cases simply need a unique identifier for the internal rule set being referred to. I'll repeat what I keep saying ... the local 'conversion' of the descriptions is not something that the TZ database has any control over, and in some cases the internal identifiers are simply that ... internal ... only requiring that they uniquely identify a particular rule set. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Apr 3, 2015, at 12:22 AM, Matt Johnson <mj1856@hotmail.com> wrote:
Personally, I'd rather see abbreviations removed entirely. If folks want them for display, they should probably get them from CLDR, where the can be properly localized.
Sounds good to me, although...
I suppose some of the historical values like those used in "war time" wouldn't be in cldr, but couldn't those be moved to a separate file?
...*somebody* would need to provide that file. Perhaps we could provide "fallback" abbreviations for everything, but that might not sufficiently encourage vendors of software using the tz database from using the CLDR rather than the TZ database. The CLDR is set up with "metazones"; a given tzdb zone might use multiple metazones, e.g. <timezone type="Atlantic/Azores"> <usesMetazone to="1992-09-27 02:00" mzone="Azores"/> <usesMetazone to="1993-03-28 01:00" from="1992-09-27 02:00" mzone="Europe_Western"/> <usesMetazone from="1993-03-28 01:00" mzone="Azores"/> </timezone> The en.xml file in the copy of the CLDR I have says: <metazone type="Azores"> <long> <generic>Azores Time</generic> <standard>Azores Standard Time</standard> <daylight>Azores Summer Time</daylight> </long> </metazone> so it supplies three long names - and *no* abbreviations - for the "Azores" metazone. It also supplies no abbreviations for "Europe_Western". So we might want to supply abbreviations for the benefit of software that *has* to provide them, e.g. so as not to surprise UN*X software that expects them in the output of, for example, the "date" command, and have a strong disclaimer that the abbreviations might have been made up by the tzdb maintainers and that one should *not* expect people in the locale in question to use them. Then we should somehow try to encourage the development of new UN*X APIs to get "long" time zone names and the deprecation of the use of the abbreviations and the tzname[] array that points to them. Perhaps by 2038 UN*X programs will no longer use the abbreviations. :-)
Then we should somehow try to encourage the development of new UN*X APIs to get "long" time zone names and the deprecation of the use of the abbreviations and the tzname[] array that points to them.
Early POSIX drafts referred to "time zone name;" after some effort, this was changed to "time zone name or abbreviation." So there's standard recognition that names are distinct from abbreviations and that both can be useful. @dashdashado On Fri, Apr 3, 2015 at 7:29 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Apr 3, 2015, at 12:22 AM, Matt Johnson <mj1856@hotmail.com> wrote:
Personally, I'd rather see abbreviations removed entirely. If folks want them for display, they should probably get them from CLDR, where the can be properly localized.
Sounds good to me, although...
I suppose some of the historical values like those used in "war time" wouldn't be in cldr, but couldn't those be moved to a separate file?
...*somebody* would need to provide that file. Perhaps we could provide "fallback" abbreviations for everything, but that might not sufficiently encourage vendors of software using the tz database from using the CLDR rather than the TZ database.
The CLDR is set up with "metazones"; a given tzdb zone might use multiple metazones, e.g.
<timezone type="Atlantic/Azores"> <usesMetazone to="1992-09-27 02:00" mzone="Azores"/> <usesMetazone to="1993-03-28 01:00" from="1992-09-27 02:00" mzone="Europe_Western"/> <usesMetazone from="1993-03-28 01:00" mzone="Azores"/> </timezone>
The en.xml file in the copy of the CLDR I have says:
<metazone type="Azores"> <long> <generic>Azores Time</generic> <standard>Azores Standard Time</standard> <daylight>Azores Summer Time</daylight> </long> </metazone>
so it supplies three long names - and *no* abbreviations - for the "Azores" metazone. It also supplies no abbreviations for "Europe_Western".
So we might want to supply abbreviations for the benefit of software that *has* to provide them, e.g. so as not to surprise UN*X software that expects them in the output of, for example, the "date" command, and have a strong disclaimer that the abbreviations might have been made up by the tzdb maintainers and that one should *not* expect people in the locale in question to use them.
Then we should somehow try to encourage the development of new UN*X APIs to get "long" time zone names and the deprecation of the use of the abbreviations and the tzname[] array that points to them.
Perhaps by 2038 UN*X programs will no longer use the abbreviations. :-)
On Apr 3, 2015, at 4:29 PM, Guy Harris <guy@alum.mit.edu> wrote:
Then we should somehow try to encourage the development of new UN*X APIs to get "long" time zone names and the deprecation of the use of the abbreviations and the tzname[] array that points to them.
Or, if we *do* include APIs to get "short" time zone names, i.e. abbreviations, allow them to return NULL and have them do so rather than return made-up abbreviations - i.e., if the CLDR has an abbreviation, return it, otherwise return NULL.
participants (4)
-
Arthur David Olson -
Guy Harris -
Lester Caine -
Matt Johnson