Internationalization: Support for IANA time zones

Dean Landolt dean at deanlandolt.com
Sat Mar 2 07:27:07 PST 2013


On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ <mark at macchiato.com> 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 <
ecmascript at lindenbergsoftware.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130302/cfdd01fa/attachment-0001.html>


More information about the es-discuss mailing list