Open cutterbl opened 4 months ago
Thanks for the report. I verified that this seems to be an issue in either ICU or in how engines call ICU.
The range pattern gets selected from here:
https://www.unicode.org/cldr/charts/44/by_type/date_&_time.gregorian.html#153a46c24508d0d4
The selected pattern is E, M/d/y – E, M/d/y
. The spec then says that this pattern should be changed to match the field widths in the request:
If no match was found from the previous step, check what the closest match is in the fallback locale chain, as in availableFormats. That is, this allows for adjusting the string value field's width, including adjusting between "MMM" and "MMMM", and using different variants of the same field, such as 'v' and 'z'.
https://unicode.org/reports/tr35/tr35-dates.html#intervalFormats
So it should change M
to MM
, but it seems something is missing and it is not doing that transformation.
The root cause may be https://unicode-org.atlassian.net/browse/ICU-12076
CC @anba @FrankYFTang @Constellation for input on whether there is anything in the engines that could be causing this behavior or if it is indeed inside of ICU.
Yes, this is caused by ICU. The spec actually allows this behaviour, though. FormatDateTimePattern selects the formatting options from rangeFormatOptions
, which can have different options than what's stored in dateTimeFormat
.
Maybe related: https://g-issues.chromium.org/issues/346328635
we need to figure is that came from CLDR pattern issue or not first.
Consider the following
What You Currently See
Wed, 2/14/2024 – Thu, 2/15/2024
What Is Expected
Wed, 02/14/2024 – Thu, 02/15/2024
If you call just
format()
then the output is according to the definition (2-digit
month), but when usingformatRange()
you get an incorrectmonth
output (numeric
month).It does this in all current major browser versions (Chrome, Edge, FF and Safari)