On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ <[email protected]> wrote:
> > 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.) > Maybe I'm missing something but ISTM there's an important difference between "Center, North Dakota" and "+09:00" -- DST. I agree it doesn't make sense to solve this problem in the context of formatting, but there wouldn't be an issue if we had a way to set the zone of a Date. In another thread it was claimed that "A Date is intended to represent a specific instance in time, irrespective of time zone". But this isn't true at all -- a Date already carries around a timezone tag internally. And if you believe there's no use case for changing a date's timezone, try partitioning a set of Dates by day (or week, month, year, etc.) using a day boundary in a timezone other the current locale's or Zulu. I've come up against this use case more than once, and The solution * sucks*. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix... A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols. Per the OP there we still need a mechanism to key the zone symbols -- I don't understand this problem enough to say for sure but the mechanism Mark described seems as good as any. As for how to query for a particular exemplar city and what to do if not present -- this could be reduced to a library problem. This feature belongs in the language. It solves a real problem (as evidenced by the libraries already built). But shipping all or part of the Olsen db is madness -- the client already has it. 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
