Discuss
  • Proposal for NumberFormat and DateTimeFormat constructors

Proposal for NumberFormat and DateTimeFormat constructors

# Norbert Lindenberg (14 years ago)

The current specs for the NumberFormat and DateTimeFormat constructors in the ECMAScript internationalization API provide for 3 (NumberFormat) or 2 (DateTimeFormat) different ways to specify the desired formats: using style properties, using skeleton properties, and (for NumberFormat) using patterns. Skeletons for NumberFormat are awaiting clarification, and Eric (Microsoft) has proposed an alternative for DateTimeFormat skeletons.

I've been thinking about how this can be streamlined, and would like to propose:

  1. Remove patterns from NumberFormat. I can imagine a few clients for which patterns would be useful, such as spreadsheet-type applications or value-added internationalization libraries. However, they require clients to provide localized patterns, and the number of applications for which this is both necessary and reasonable is fairly small. Most applications are better off using styles or skeletons, which let the implementation of the internationalization API fully take care of localization. (Patterns would actually be more useful for DateTimeFormat, where the limited number of supported skeletons will force more clients to roll their own, but there we don't offer them.)

  2. Drop skeletons from NumberFormat, and instead offer additional properties through which clients can taylor the selected format style to their needs. I've written up an API proposal that provides the same functionality as skeletons.

  3. Merge styles, skeletons, and the Microsoft proposal for DateTimeFormat into a unified approach with style values that are skeleton-like, but easier to understand, and can be added to in future versions of the API. I've written up an API proposal for this as well.

The API proposals are located at: norbertlindenberg.com/ecmascript/internationalization-formats.html

Best , Norbert

# Nebojša Ćirić (14 years ago)

Added to the main document. Thanks for the input.

  1. август 2011. 16.57, Norbert Lindenberg <ecmascript at norbertlindenberg.com
# John Tamplin (14 years ago)

On Tue, Aug 16, 2011 at 7:57 PM, Norbert Lindenberg < ecmascript at norbertlindenberg.com> wrote:

The current specs for the NumberFormat and DateTimeFormat constructors in the ECMAScript internationalization API provide for 3 (NumberFormat) or 2 (DateTimeFormat) different ways to specify the desired formats: using style properties, using skeleton properties, and (for NumberFormat) using patterns. Skeletons for NumberFormat are awaiting clarification, and Eric (Microsoft) has proposed an alternative for DateTimeFormat skeletons.

I've been thinking about how this can be streamlined, and would like to propose:

  1. Remove patterns from NumberFormat. I can imagine a few clients for which patterns would be useful, such as spreadsheet-type applications or value-added internationalization libraries. However, they require clients to provide localized patterns, and the number of applications for which this is both necessary and reasonable is fairly small. Most applications are better off using styles or skeletons, which let the implementation of the internationalization API fully take care of localization. (Patterns would actually be more useful for DateTimeFormat, where the limited number of supported skeletons will force more clients to roll their own, but there we don't offer them.)

Maybe we are calling different things patterns, but if I pass in "#,###.00" as the pattern to ICU4J's DecimalFormat, then that will get localized to the proper grouping separator, number of grouping digits, and decimal separator -- the caller doesn't have to localize it at all.

I think more applications than you think will want some control over the format pattern -- for example, if I am showing a table of currencies, I probably don't want to include the currency symbol in every cell in the table, but I still want them formatted appropriately for the currency (right number of decimal positions, round to multiple of .05 for CHF, etc).

I would argue that patterns are actually less useful in DateTimeFormat, as it encourages developers to do the wrong thing. Ie, if I use "MM/dd/yyyy" as the pattern for DateTimeFormat, then the result will be misleading in locales where such a date would be formatted as "dd/MM/yyyy". I think it would be better to support skeleton patterns instead, where the app asks for a pattern containing numeric days, months and a 4-digit year, and then it gets the proper localized pattern that matches that.

The one case where specifying patterns explicitly is useful is compliance with specs - for example, RFC2822 or ISO8601 dates (which also need to force English names in the cae of RFC2822).