Intl.DateTimeFormat is not consistence with browser's Intl.DateTimeFormat

[xiao-kevin]

Intl.js generate a "at" between year and time.

For example: Monday, September 24, 2012 at 1:20 PM But in the browse's implementation it will be Monday, September 24, 2012 1:20 PM

[caridy]

@xiao-kevin we need more details, what exactly are the config and the locale that you're using... etc.

[xiao-kevin]

Sure, here are two examples:

new Intl.DateTimeFormat('en-US', { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric', hour: 'numeric', minute: '2-digit'}).format(1348518027)

Intl.js: Friday, January 16, 1970 at 6:35 AM Chrome v53: Friday, January 16, 1970, 6:35 AM

new Intl.DateTimeFormat('en-US', { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric', hour: 'numeric', minute: '2-digit'}).format(Date.now());

Intl.js: Friday, October 14, 2016 at 11:19 AM Chrome v53: Friday, October 14, 2016, 11:19 AM

[singles]

Looks like I have similar case, compare those:

new Intl.DateTimeFormat('en', {
    weekday: 'long',
    day: '2-digit',
    month: '2-digit',
    year: '2-digit' }
).format(new Date(0));
// returns
'Thursday, 01/01/70' //work the same natively in browser without `intl` package

while in node env:

var i18n = require('intl')
Intl.DateTimeFormat = i18n.DateTimeFormat
[Function: DateTimeFormatConstructor]

new Intl.DateTimeFormat('en', {
    weekday: 'long',
    day: '2-digit',
    month: '2-digit',
    year: '2-digit' }
).format(new Date(0))
// gives you
'Thu, 1/1/1970'

[caridy]

@xiao-kevin there might be something that we can do about this. Today, when combining time and date values into a single output, we rely on what CLDR give us, which is: https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/en-US.json#L11-L14

for some reason, we are choosing full or long (which are the one that include the at), instead of using medium or short.

Here is the actual code that choose the format for the concatenation: https://github.com/andyearnshaw/Intl.js/blob/master/src/cldr.js#L290-L296

Clearly, it is choosing long based on your settings, I wonder why browsers are doing the opposite :). Since this is not part of the spec, this is the free-form used by browsers to choose the best match, we will have to dig in more to try to find the right balance.

@singles that's a different problem since you're not combining time and date, feel free to open a separate issue.

[ffasolin]

@singles I have a similar issue, any luck fixing it?

[singles]

@ffasolin TBH I don't know, not working on this part of our codebase anymore.