Internationalization: Support for IANA time zones

Mark Davis ☕ mark at macchiato.com
Sat Mar 2 02:11:05 PST 2013


> 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 <
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130302/d176d440/attachment.html>


More information about the es-discuss mailing list