Internationalization: Additional values in API

Norbert Lindenberg ecmascript at norbertlindenberg.com
Wed Jun 27 11:43:45 PDT 2012


Replies below.

Norbert


On Jun 26, 2012, at 16:02 , Mark Davis ☕ wrote:

> On Tue, Jun 26, 2012 at 3:22 PM, Norbert Lindenberg <ecmascript at norbertlindenberg.com> wrote:

>> - The options properties style, currencyDisplay, minimumIntegerDigits, minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, and maximumSignificantDigits in the NumberFormat constructor.
> 
> The ones that are integers it would seem odd to accept others.

I should clarify for these that the acceptable additional values would be higher numbers, similar to
http://ecma-international.org/ecma-262/5.1/#sec-15.7.4.5

>> - The options property timeZone in the DateTimeFormat constructor, provided that the additional acceptable input values are case-insensitive matches of Zone or Link identifiers in the IANA time zone database [2] and are canonicalized to Zone identifiers in the casing used in the database for DateTimeFormat.resolvedOptions().timeZone, except that "Etc/GMT" shall be canonicalized to "UTC".
> 
> I agree with your reasoning below, but would I would rather use the CLDR values in http://unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml, since they are based on the TZDB but mroe stable. Either just names or names + aliases.

If the time zone naming schemes of both IANA and CLDR were new proposals, you might be able to convince me that the CLDR scheme is better. However, the IANA time zone names have been around for much longer and are far more widely supported. The ICU API, for example, is based on IANA time zone names, and looking through the time zone related documentation I can't find any support for the CLDR names.
http://userguide.icu-project.org/datetime/timezone
http://icu-project.org/apiref/icu4c/classTimeZone.html



More information about the es-discuss mailing list