andyearnshaw / Intl.js

Compatibility implementation of the ECMAScript Internationalization API (ECMA-402) for JavaScript -- UNMAINTAINED
Other
1.7k stars 215 forks source link

Long eras show short eras #209

Open icambron opened 8 years ago

icambron commented 8 years ago

I'm not sure this is not related to #190, but since the fix doesn't seem to address eras, my guess is not. It looks like there is data for long era names, but they don't work:

> new poly.DateTimeFormat('en', {era: 'long'}).resolvedOptions()
{ locale: 'en',
  calendar: 'gregory',
  numberingSystem: 'latn',
  timeZone: undefined,
  era: 'short',
  year: 'numeric',
  month: 'short',
  day: 'numeric' }
> new poly.DateTimeFormat('en', {era: 'long'}).format()
'Aug 4, 2016 AD'

Compare to Chrome (whose choices for this are strange, but the era part works):

new Intl.DateTimeFormat('en', {era: 'long'}).format()
"8 4, 2016 Anno Domini"
caridy commented 8 years ago

@icambron when using only era: "long", it ended up using: https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/en.json#L38

Era can't be produced alone by browsers today, the patch for single entries will not cover it. That being said, we should keep improving the best match. In this case, if all browsers behave the same, we can simply define that from short to long values on era, the user entry have preference.

icambron commented 8 years ago

To be clear, I'm OK not producing it alone. But I wasn't able to find any combination settings that gave me a long era. I suppose that's consistent with all of those formats you pointed to only using "G" and never "GGGG" (or whatever CLDR's code for long era is), but still surprising that there's a setting which can in no circumstances have an effect.

if all browsers behave the same, we can simply define that from short to long values on era

If I understand this correctly, it makes good sense. Are you saying that if there's a "[whatever] G" in the source data, then automatically also have a "[same whatever] GGGG"?

caridy commented 8 years ago

@icambron yes, that is actually specified in CLDR here http://www.unicode.org/reports/tr35/tr35-dates.html#Matching_Skeletons, specifically, the definition of close distance between settings where the user-input config can force the pattern/skeleton to produce something more accurate. We haven't get to the point where this close distance is implemented, but I have put in place all the pieces to support it, it is just a matter of finding time and support :) or a brave soul willing to implement it! ;)