Proposal for NumberFormat and DateTimeFormat constructors

John Tamplin jat at
Wed Aug 17 12:26:10 PDT 2011

On Tue, Aug 16, 2011 at 7:57 PM, Norbert Lindenberg <
ecmascript at> 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).

John A. Tamplin
Software Engineer (GWT), Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list