Intl.DateTimeFormat returns month:long instead of month:short

[fhemberger]

global.Intl = require('intl');
var date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
var options = {year: "numeric", month: "short", day: "numeric"};
console.log(new Intl.DateTimeFormat("en", options).format(date));

Expected: Dec 20, 2012
Actual: December 20, 2012

[fhemberger]

Actually, there is more strange behavior going on in DateTimeFormat. For the same code snippet as above, set options to

var options = {
    day: "2-digit", month: "2-digit", year: "2-digit",
    hour: "numeric", minute : "numeric"
};

Expected: 12/20/12 4:00 AM (Tested in latest Chrome and Firefox)
Actual: Thursday, December 20, 2012, 4:00:00 AM

[triptych]

Here's a jsfiddle with another example. "Works" in Chrome since I think it's using the built-in Intl, but fails in Safari using Intl.js

(Updated with example that show's the month:long / month:short issue spelled out in this bug. Previous example was based on 0.1.2)

http://jsfiddle.net/triptych/JDgz4/

[caridy]

This might be related to: #65 (comment)

[andyearnshaw]

It is indeed related to #65. I've pretty much already decided to no longer have Intl.js preparse date formats, instead the logic for it will be moved into the main Intl.js code, which will mean a wider range of formats at a much lower data cost (albeit at the expense of a small performance penalty).

Though I'd closed some of these in the past as dupes, I'm leaving this open; it's next on the list after I get some feedback for and complete #67 😉.

[bakura10]

Hi,

I still experience this issue. Is there any way to fix it on polyfill (Chrome shows "Nov. 4, 2014" while Polyfill shows "November 4, 2014"

[bakura10]

ping @jasonmit

Could we have someone at Yahoo to fix this very long-awaited bug? I've tried to dig into the code myself but definitely too obscure for me. I know this must be a complex piece of software, but having date not correctly showing on Safari and iOS since nearly one year is quite annoying, actually :(.

Thanks in advance! :)

[caridy]

ok, we will try to get someone to fix this. /cc @jlecomte @ericf

[bakura10]

Thanks! ;)

[okuryu]

I'll try to take a look if no one else wants to do. :)

[andyearnshaw]

@okuryu that would be an enormous help. The reason I haven't gotten round to it is that I don't have much time for personal projects and this is not a simple change. As per #77, we need to remove the data pre-compiling step and move some of the logic from the data compiler to the main formatting code.

Side note: this isn't strictly a bug, Intl.js actually supports the minimum subsets of date formats required by the specification.

[ericf]

Side note: this isn't strictly a bug, Intl.js actually supports the minimum subsets of date formats required by the specification.

We can also file a bug against the spec to see if it's possible for it to add more specification around the output of the formatters — although it's likely to be a big can a worms.

[andyearnshaw]

I think those subsets were chosen as some locales will be missing some
formats. It's not even required (but it is recommended) that
implementations use CLDR, so there's always a chance of different outputs
in different environments. Norbert could probably tell you the exact
reasons.