Replies below. Norbert
On Jun 26, 2012, at 16:02 , Mark Davis ☕ wrote: > On Tue, Jun 26, 2012 at 3:22 PM, Norbert Lindenberg > <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
