> 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?
I agree. (And you hit on an important point above.) Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg < [email protected]> wrote: > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
