Open icambron opened 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.
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"?
@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! ;)
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:
Compare to Chrome (whose choices for this are strange, but the era part works):