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

Long month is shown as short month #107

Closed
danieljuhl opened this issue Jun 17, 2015 · 17 comments · Fixed by #111
Closed

Long month is shown as short month #107

danieljuhl opened this issue Jun 17, 2015 · 17 comments · Fixed by #111

Comments

@danieljuhl
Copy link

Given the options { year: 'numeric', month: 'long', day: 'numeric' } or { year: 'numeric', month: 'short', day: 'numeric' }, both produces 1 Jul 2015 for new Intl.DateTimeFormat( 'en-GB', options ).format( new Date('2015-07-01') )

The same is reproduced using locale da-DK, producing 1. jul. 2015.

I would expect 1 July 2015 and in Danish 1. juli 2015

@caridy
Copy link
Collaborator

caridy commented Jun 17, 2015

@danieljuhl this was fixed in intl@1.0.0-rc-1, which was released few days ago.

@caridy caridy closed this as completed Jun 17, 2015
@danieljuhl
Copy link
Author

What is wrong with my issue?

I've just upgraded to 1.0.0-rc-1, and this issue is still present ( actually it is a new issue, because the old behaviour was the other way round - short month showing as long month, but now it is long month showing as short )

@caridy
Copy link
Collaborator

caridy commented Jun 18, 2015

Well, after looking into the data, the only thing I can tell you is that the logic seems to be fine, and the CLDR data seems to be incomplete (as on version 26). Take for example es locale:

> new IntlPolyfill.DateTimeFormat( 'es', { month: 'long', day  : 'numeric', year : 'numeric'}).format(Date.now())
'18 de jun. de 2015'
> new IntlPolyfill.DateTimeFormat( 'es', { month: 'long', day : 'numeric' }).format(Date.now())
'18 de junio'
> new IntlPolyfill.DateTimeFormat( 'es', { month: 'long', year: 'numeric' }).format(Date.now())
'junio de 2015'

As you can see, in some cases, even with the month set to long it will choose the closest match, which is a pattern with a short month value. Sometimes, it does have the exact match. When looking at what CLDR date format pattern definitions:

           "availableFormats": {
                "E": "ccc",
                "EHm": "E, H:mm",
                "EHms": "E, H:mm:ss",
                "Ed": "E d",
                "Ehm": "E, h:mm a",
                "Ehms": "E, h:mm:ss a",
                "Gy": "y G",
                "GyMMM": "MMM 'de' y G",
                "GyMMMEd": "E, d 'de' MMMM 'de' y G",
                "GyMMMd": "d MMM 'de' y G",
                "H": "H",
                "Hm": "H:mm",
                "Hms": "H:mm:ss",
                "M": "L",
                "MEd": "E, d/M",
                "MMM": "LLL",
                "MMMEd": "E, d 'de' MMM",
                "MMMMd": "d 'de' MMMM",
                "MMMd": "d 'de' MMM",
                "MMMdd": "d 'de' MMM",
                "MMd": "d/M",
                "MMdd": "d/M",
                "Md": "d/M",
                "d": "d",
                "h": "h a",
                "hm": "h:mm a",
                "hms": "h:mm:ss a",
                "ms": "mm:ss",
                "y": "y",
                "yM": "M/y",
                "yMEd": "EEE, d/M/y",
                "yMM": "M/y",
                "yMMM": "MMM 'de' y",
                "yMMMEd": "EEE, d 'de' MMMM 'de' y",
                "yMMMM": "MMMM 'de' y",
                "yMMMd": "d 'de' MMM 'de' y",
                "yMd": "d/M/y",
                "yQQQ": "QQQ y",
                "yQQQQ": "QQQQ 'de' y"
            }

there are only 4 of them that are using MMMM, which is equivalent to long month value, and those are:

"GyMMMEd": "E, d 'de' MMMM 'de' y G",
 "MMMMd": "d 'de' MMMM",
 "yMMMEd": "EEE, d 'de' MMMM 'de' y",
 "yMMMM": "MMMM 'de' y",

And those are working well. The question at this point is: where is that data coming from that browsers are producing the right value for a custom setting like:

> new Intl.DateTimeFormat( 'en', { month: 'long', day  : 'numeric', year : 'numeric'}).format(new Date("2005-12-11"))
'December 11, 2005'    // <-- browser value
> new IntlPolyfill.DateTimeFormat( 'en', { month: 'long', day  : 'numeric', year : 'numeric'}).format(new Date("2005-12-11"))
'Dec 11, 2005'              // <-- polyfill value

/cc @rxaviers @srl295 @andyearnshaw

@caridy
Copy link
Collaborator

caridy commented Jun 18, 2015

Ok, I think I've cracked this one. There are two set of values that are not used today in our algo, and those are defined at the same level as availableFormats per calendar, here is what we have there for en:

          "dateFormats": {
              "full": "EEEE, MMMM d, y",
              "long": "MMMM d, y",
              "medium": "MMM d, y",
              "short": "M/d/yy"
            },
            "timeFormats": {
              "full": "h:mm:ss a zzzz",
              "long": "h:mm:ss a z",
              "medium": "h:mm:ss a",
              "short": "h:mm a"
            },

We just need to figure how to use them :), I will investigate more.

@danieljuhl
Copy link
Author

@caridy As far as I see, I still have the problem as well.

@rxaviers
Copy link

@caridy, UTS#35 specifies that CLDR doesn't "supply dateFormatItems with skeletons for every field length; in many cases fields in the skeleton and pattern can be expanded in parallel to handle a request". http://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems. Although, the spec doesn't suggest or guide the implementation. It seems your #111 fix is doing the right thing by expanding the fields by itself.

@srl295 could shed some light on how this works on ICU.

@andyearnshaw andyearnshaw reopened this Jun 19, 2015
@caridy
Copy link
Collaborator

caridy commented Jun 19, 2015

@danieljuhl check intl@1.0.0-rc-4 which is the one including this fix.

@caridy caridy closed this as completed Jun 19, 2015
@danieljuhl
Copy link
Author

@caridy It seems to work.. I've tested both long and short month format with numeric day and year, and they both give the expected result, and the same result as native Intl in Chrome. Thanks for the quick fixes!

@jasonmit
Copy link

Thanks @caridy 👍

@ollym
Copy link
Contributor

ollym commented Jun 25, 2015

@caridy I'm still seeing this issue in RC4

@caridy
Copy link
Collaborator

caridy commented Jun 26, 2015

@ollym can you describe in details what you're seeing? can you do a prove of concept for me to debug it?

@ollym
Copy link
Contributor

ollym commented Jun 26, 2015

@caridy straight from my iPhone (Safari on iOS has no native Intl support yet):

screen shot 2015-06-26 at 10 57 51

@Ianfeather
Copy link

I still see this issue across browsers when trying to display just the month.

IntlPolyfill.DateTimeFormat('en-US', {month: 'long'}).resolvedOptions()
// Object {locale: "en-US", month: "short", calendar: "gregory", numberingSystem: "latn", timeZone: undefined}
Intl.DateTimeFormat('en-US', {month: 'long'}).resolvedOptions()
// Object {locale: "en-US", month: "long", numberingSystem: "latn", calendar: "gregory", timeZone: "Europe/London"}

Is there a way to get around this? I'm using 1.0.1.

@caridy
Copy link
Collaborator

caridy commented Jan 26, 2016

you can check this branch #146, I will try to land it as 1.0.2 soon :)

@Ianfeather
Copy link

Thanks, I'll try it out!

@caridy
Copy link
Collaborator

caridy commented Jan 27, 2016

please, let us know if that works for you.

@Ianfeather
Copy link

Could you give me any tips on how to test this out?

Installing via npm (pointing to the branch) doesn't give me any way to build it (that I see). Cloning the repo and then building it with grunt and copying it across gives me errors that imply some formats are missing:

TypeError: Cannot read property 'replace' of undefined
    at Object.createDateTimeFormats (/Users/ian/schibsted/spt-koa-intl/node_modules/intl/lib/cldr.js:349:17)
    at ToDateTimeFormats (/Users/ian/schibsted/spt-koa-intl/node_modules/intl/lib/core.js:2026:23)
    at InitializeDateTimeFormat (/Users/ian/schibsted/spt-koa-intl/node_modules/intl/lib/core.js:1891:19)

fixing that one error ^^ leads to other similar ones.

What other steps do I need to do? Happy to help if I can get started.

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

Successfully merging a pull request may close this issue.

7 participants