And the time zone names in formatted output when no localized time zone name is available:
On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote: > 5) The set of combinations of time zone name and language tag for which > localized time zone names are available is implementation dependent. Where no > localized time zone name is available, the canonicalized name is used in > formatted output. > > The last one I'm not entirely comfortable with: IANA time zone names can be > long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes people > think the wrong representative city was selected (e.g., Shanghai rather than > Beijing for China). An alternative might be to prescribe formatting as an > offset from UTC. On Feb 28, 2013, at 16:13 , Shawn Steele wrote: > For #5 I might prefer falling back to English or something. I don't think > UTC offset is a good idea because that doesn't really represent a Timezone > very well. (If a meeting gets moved to a following week, that offset might > change or be wrong) On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote: > This is a problematic. The canonicalized names are very ugly. What we do in > CLDR is return the last label, after some modifications (in > http://www.unicode.org/repos/cldr/trunk/common/main/root.xml). We don't want > to return the raw IDs. I think this needs to be implementation dependent. > > For example: > > <zone type="Antarctica/DumontDUrville"> > <exemplarCity>Dumont d’Urville</exemplarCity> > </zone> > <zone type="America/North_Dakota/Center"> > <exemplarCity>Center, North Dakota</exemplarCity> > </zone> > > So I think we should just have #5 be: > > 5) The set of combinations of time zone name and language tag for which > localized time zone names are available is implementation dependent. On Mar 1, 2013, at 9:41 , Phillips, Addison wrote: > I think the least surprise would result if the GMT+/- string were used when > no local representation is available. While the actually time zone is more > specific, most callers are just trying to put a date or time value into their > output for human consumption. In most cases, the DST transition rules are > unimportant to a specific date value being rendered and the GMT offset is at > least somewhat compact. Users are probably more familiar with this > presentation and certainly will be happier with it than "America/Los_Angeles". It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. Maybe there's just no value in trying to define something in the standard since any implementer can claim that "Center, North Dakota" and "GMT+09:00" are localized representations for some locale. So, leave it all implementation dependent? Norbert _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
