[Discussion] Create instances of DateTimeFormat and NumberFormat without the first argument locale is problematic

[caridy]

In most cases, when doing new Intl.DateTimeFormat().format(1234); on the client side will work well since it will use the user's preferences to render the date, but that's not the case of nodejs/iojs when rendering data on the server side since that will rely on the server's preferences rather than the user's preferences to render that piece of data.

Ideally, developers will alway negotiate the locale per request, and use it to create new instances of DateTimeFormat and NumberFormat, but some might call this an unnecessary overhead. What are your thoughts around this? Should we have a mode where we warn about this? Should we try to negotiate with ECMA402 to have a more comprehensive solution around the default locale?

On top of this, most people will end up caching instances of DateTimeFormat and NumberFormat between requests because the fact that they are very very expensive to create compared to traditional javascript objects, I wonder if we should provide some out-of-the-box instances in node.

[kevinmartin]

Part of me wants to say that I think that the default should be the server preferences. I don't think there should be a specific default locale, though.

As far as providing out-of-the-box instances in node, I personally disagree with. It will just slow down app startup times for people who:

• don't know about those instances
• don't use DateTimeFormat/NumberFormat
• need instances other than the out-of-the-box instances

The users that can benefit from the out-of-the-box instances can easily do:

global.dateTimeFormat = new Intl.DateTimeFormat(...);
global.numberFormat = new Intl.NumberFormat(...);

at boot time in their main app script.

[caridy]

@kevinmartin I was referencing to a mechanism "per request" right after negotiating the locale (when constructing the request object maybe). But the reality is that ECMA402 does not help with this since options is required when creating those instances, which makes this a complicated thing.

Btw, doing global.* is not recommended for Intl instances since the locale should be negotiated per request, and not during server start time.

[kevinmartin]

I see, sorry. I was seeing your points from a global perspective, since not everyone uses Node for it's HTTP server capabilities.

So, what you're suggesting would deal solely with the http/https modules, correct? Regardless, I personally feel creating (an expensive) object per request that may or may not be used/known will in itself be too expensive to do. It should be kept to the developer to create/cache those instances.

[srl295]

I think the above ^ is best discussed as ecma402, so i am closing this