-
Notifications
You must be signed in to change notification settings - Fork 215
Long month is shown as short month #107
Comments
@danieljuhl this was fixed in intl@1.0.0-rc-1, which was released few days ago. |
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 ) |
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 > 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 "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
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:
|
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 "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. |
@caridy As far as I see, I still have the problem as well. |
@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. |
@danieljuhl check intl@1.0.0-rc-4 which is the one including this fix. |
@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! |
Thanks @caridy 👍 |
@caridy I'm still seeing this issue in RC4 |
@ollym can you describe in details what you're seeing? can you do a prove of concept for me to debug it? |
@caridy straight from my iPhone (Safari on iOS has no native Intl support yet): |
I still see this issue across browsers when trying to display just the month.
Is there a way to get around this? I'm using 1.0.1. |
you can check this branch #146, I will try to land it as 1.0.2 soon :) |
Thanks, I'll try it out! |
please, let us know if that works for you. |
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:
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. |
Given the options
{ year: 'numeric', month: 'long', day: 'numeric' }
or{ year: 'numeric', month: 'short', day: 'numeric' }
, both produces1 Jul 2015
fornew Intl.DateTimeFormat( 'en-GB', options ).format( new Date('2015-07-01') )
The same is reproduced using locale
da-DK
, producing1. jul. 2015
.I would expect
1 July 2015
and in Danish1. juli 2015
The text was updated successfully, but these errors were encountered: