Scheduling - use case for acronyms
Was: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect On Tue, Apr 2, 2013 at 7:08 PM, Russ Allbery <rra@stanford.edu> wrote:
Humans don't need the abbreviation and don't care. False - as numerous emails and usages demonstrate.
They either schedule the meeting in local time That might be unknown or ambiguous.
or in the current time in some other time zone Exactly, and that would be communicated how, in a brief manner - as Mark used in "Mondays at 8:00 PT"
(or possibly in UTC) UTC might be unknown at time of scheduling or not decipherable by the receiver.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 2 April 2013 19:42, Tobias Conradi <tobias.conradi@gmail.com> wrote:
Exactly, and that would be communicated how, in a brief manner - as Mark used in "Mondays at 8:00 PT"
On the other hand, if the meeting took place in Berlin, some would say "Mondays at 8:00 CET" while others would say "an Montagen um 8:00 MEZ". Which is a case for placing such time zone abbreviations in localisation frameworks such as CLDR rather than in the tz database. Cheers, Philip -- Philip Newton <philip.newton@gmail.com>
On Tue, Apr 2, 2013, at 15:11, Philip Newton wrote:
On 2 April 2013 19:42, Tobias Conradi <tobias.conradi@gmail.com> wrote:
Exactly, and that would be communicated how, in a brief manner - as Mark used in "Mondays at 8:00 PT"
On the other hand, if the meeting took place in Berlin, some would say "Mondays at 8:00 CET" while others would say "an Montagen um 8:00 MEZ".
Which is a case for placing such time zone abbreviations in localisation frameworks such as CLDR rather than in the tz database.
Yes, it is. And, in fact, there are time zone abbreviations in CLDR. However, there are no C implementations that natively support the time zone abbreviations in CLDR - in no small part, I suspect, due to the lack of any support for either localized timezone abbreviations or metazone specification in the tzfile binary format. Metazones, for those who don't already know, are things that group zones that are "the same timezone" (e.g. the two dozen or so U.S. and Canada -05:00 EST/-04:00 EDT zones are all "America_Eastern", your CET/MEZ/whatever are all "Europe_Central", etc) together, and are the key used to look up the localized timezone names and abbreviations. They include a standard and daylight offset, and of course a name, but _not_ the question of whether DST is used at all, or what the specific changeover dates for it are. The data is at http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml, but note that it does not cover changes before 1970 (for example, America/Indianapolis is simply mapped to America_Eastern, rather than showing it should be America_Central before 1955 Apr 24 and from 1957 Sep 29 to 1958 Apr 27.) Really, metazone specification itself seems like it _should_ be the domain of tz rather than CLDR. But it would require an incompatible extension to the syntax of the timezone source files.
On Tue, Apr 2, 2013 at 9:37 PM, <random832@fastmail.us> wrote:
On Tue, Apr 2, 2013, at 15:11, Philip Newton wrote:
On 2 April 2013 19:42, Tobias Conradi <tobias.conradi@gmail.com> wrote:
Exactly, and that would be communicated how, in a brief manner - as Mark used in "Mondays at 8:00 PT"
On the other hand, if the meeting took place in Berlin, some would say "Mondays at 8:00 CET" while others would say "an Montagen um 8:00 MEZ".
Which is a case for placing such time zone abbreviations in localisation frameworks such as CLDR rather than in the tz database.
Yes, it is. To what ID in the IANA time zone database would a localization database connect to?
And, in fact, there are time zone abbreviations in CLDR.
Metazones, for those who don't already know, are things that group zones that are "the same timezone" Can you point to a definition?
(e.g. the two dozen or so U.S. and Canada -05:00 EST/-04:00 EDT zones are all "America_Eastern", your CET/MEZ/whatever are all "Europe_Central", etc) together, and are the key used to look up the localized timezone names and abbreviations. They include a standard and daylight offset, and of course a name, but _not_ the question of whether DST is used at all, or what the specific changeover dates for it are.
The data is at http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml, <timezone type="Africa/Algiers"> <usesMetazone to="1977-10-20 23:00" mzone="Europe_Western"/> <usesMetazone to="1979-10-25 23:00" from="1977-10-20 23:00" mzone="Europe_Central"/> <usesMetazone to="1981-05-01 00:00" from="1979-10-25 23:00" mzone="Europe_Western"/> <usesMetazone from="1981-05-01 00:00" mzone="Europe_Central"/> </timezone>
Looks like partial duplication of IANA data: ftp://ftp.iana.org/tz/data/africa Zone Africa/Algiers 0:00 Algeria WE%sT 1981 May 1:00 - CET
Really, metazone specification itself seems like it _should_ be the domain of tz rather than CLDR. But it would require an incompatible extension to the syntax of the timezone source files.
Something close might be there if the acronyms would be selected differently. E.g. using: https://tango.info/wiki/Internationalized_time_point_unique_time_zone_abbrev... EUCT (English: CET, German MEZ) EUCDT (English: CEST, German MESZ) AUCT (English: ACST) AUCDT (English: ACDT) USCT (English: CST) USCDT (English: CDT) IDET (IANA-English: EIT, Indonesian: WIT !!! ) IDWT (IANA-English: WIT !!!, Indonesian: WIB) -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On Tue, Apr 2, 2013, at 16:01, Tobias Conradi wrote:
To what ID in the IANA time zone database would a localization database connect to?
One would have to be added, which, in case you didn't notice, was the _entire point_ i was making in my post. The abbreviations aren't adequate, and you can't simply map the ID because the actual zone a location is in may have changed over time.
And, in fact, there are time zone abbreviations in CLDR.
Metazones, for those who don't already know, are things that group zones that are "the same timezone" Can you point to a definition?
Er, it is a concept unique to the CLDR itself. What it _does_ is obvious from the data.
participants (3)
-
Philip Newton -
random832＠fastmail.us -
Tobias Conradi