Skip to content
This repository was archived by the owner on Apr 14, 2021. It is now read-only.

Intl.DateTimeFormat with just one option #75

Closed
juandopazo opened this issue Sep 23, 2014 · 12 comments
Closed

Intl.DateTimeFormat with just one option #75

juandopazo opened this issue Sep 23, 2014 · 12 comments

Comments

@juandopazo
Copy link
Contributor

Intl.DateTimeFormat seems to work fine if you use all its options. For example, the behavior of the polyfill for this looks correct:

alert(new Intl.DateTimeFormat("en-US", {weekday: "long", year: "numeric", month: "long", day: "numeric"}).format(Date.now())); // Tuesday, September 23, 2014

However, when you specify only one option, the polyfill seems to include other parts of the date:

// Chrome
new Intl.DateTimeFormat("en-US", {weekday: "long"}).format(Date.now()); // Tuesday
// IE
new Intl.DateTimeFormat("en-US", {weekday: "long"}).format(Date.now()); // Tuesday
// Polyfill
new IntlPolyfill.DateTimeFormat("en-US", {weekday: "long"}).format(Date.now()); // Tuesday, September 23, 2014

/cc @caridy @ericf

@ericf
Copy link
Collaborator

ericf commented Sep 23, 2014

I also noticed this with with the following example:

var df = new Intl.DateTimeFormat('en', {year: 'numeric'});
console.log(df.format(Date.now()));

In Chrome or Firefox it outputs: "2014"
While the polyfill outputs: "9/2014"

According to the docs on MDN for Intl.DateTimeFormat:

The default value for each date-time component property is undefined, but if all component properties are undefined, then year, month, and day are assumed to be "numeric".

@syranide
Copy link

console.log(new Intl.DateTimeFormat('sv-SE', {
  year: 'numeric', month: 'long', day: '2-digit',
  hour: '2-digit', minute: '2-digit'
}).format(0));

=> 'torsdag 1 januari 1970 0:00:00' // forced weekday and seconds, also incorrect hour format

Is the DateTimeFormat plain broken or am I missing something?

@caridy
Copy link
Collaborator

caridy commented Dec 16, 2014

for what I can tell, the locale-data was reduced intentionally to support +90% of the cases in favor of not blowing up the size of the locale-data, which ultimately means that not all combinations are supported, but @andyearnshaw can provide more details.

@syranide
Copy link

Not respecting 2-digit hours doesn't seem like an issue of reduction... and while I imagine we're talking about all possible field variations = wowbig is definitely a problem, but omitting weekdays and seconds from a long date can't be that uncommon and odd of a request?

I'll just have to split it in two for now and treat date and time formatting as part of the message.

@mjackson
Copy link

I just ran into this issue as well and thought I was going crazy.

// Chrome
new Intl.DateTimeFormat('en', { month: 'short' }).format(new Date) // "Feb"
// Polyfill
new Intl.DateTimeFormat('en', { month: 'short' }).format(new Date) // "February 2015"

@andyearnshaw Can you shed any light here?

@caridy
Copy link
Collaborator

caridy commented Feb 20, 2015

related to #68, we will try to fix it asap.

@mjackson
Copy link

@caridy Thank you! ❤️

@caridy
Copy link
Collaborator

caridy commented Apr 6, 2015

fixed by #85

@ronjouch
Copy link

ronjouch commented May 1, 2015

@caridy thanks too for this fix! Fantastic work :)

@caridy
Copy link
Collaborator

caridy commented Jun 10, 2015

1.0.0-rc-1 is in NPM, help us to test it...

@caridy caridy closed this as completed Jun 10, 2015
@ghost
Copy link

ghost commented Jul 16, 2015

Following issue on Safari will return the short version of the month instead of long, using latest intl@1.0.0. Anyone else having this issue?

Intl.DateTimeFormat('en', {month: 'long'}).format(new Date()); //"Jul"

@caridy
Copy link
Collaborator

caridy commented Jul 16, 2015

@mesrob-axs yes, #125 and #126

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants