formatToParts returns 2-digit for month instead of numeric
Categories
(Core :: JavaScript: Internationalization API, defect, P3)
Tracking
()
People
(Reporter: edwin, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
160.67 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
Type this in the Firefox Console:
const date = new Date("2013-03-24T10:11:16.000Z")
dateTimeFormat = new Intl.DateTimeFormat('en-GB', { month: 'numeric', year: 'numeric'})
dateTimeFormat.formatToParts(date)
Unfold the result
Actual results:
You'll see this:
0: Object { type: "month", value: "03" }
1: Object { type: "literal", value: "/" }
2: Object { type: "year", value: "2013" }
Expected results:
It should be this:
0: Object { type: "month", value: "3" }
1: Object { type: "literal", value: "/" }
2: Object { type: "year", value: "2013" }
The month result should be "3" instead of "03".
So month was requested to give a representation of "numeric", but the result was shown as different representation, namely "2-digit".
It works fine when year is not requested to give a representation.
Comment 1•1 year ago
|
||
Chrome also gives the month as "03"
.
Updated•1 year ago
|
Comment 2•1 year ago
|
||
This happens because the underlying CLDR resources explicitly define that the two-digit format should be used when requesting the format "yM". (The date format pattern syntax is defined in https://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns.)
Reporter | ||
Comment 3•1 year ago
|
||
André Bargull: do you mean to say the the result should be "03" because of CLDR or do you mean to say the Intl implementation is using CLDR incorrectly?
The Intl.DateTimeFormat.prototype.format behavior is specified here:
https://402.ecma-international.org/1.0/#sec-12.3.2
Here, we read
-
Let nf be the result of creating a new NumberFormat object as if by the expression new Intl.NumberFormat([locale], {useGrouping: false}) where Intl.NumberFormat is the standard built-in constructor defined in 11.1.3.
-
vii. If f is "numeric", then
Let fv be the result of calling the FormatNumber abstract operation (defined in 11.3.2) with arguments nf and v.
Note that in point 3., the "minimumIntegerDigits: 2" is absent and FormatNumber.format() returns "3" instead of "03". Al least, that's how I interpret this.
Comment 4•1 year ago
|
||
(In reply to Edwin Martin from comment #3)
André Bargull: do you mean to say the the result should be "03" because of CLDR or do you mean to say the Intl implementation is using CLDR incorrectly?
The result should be "03" because of CLDR.
The Intl.DateTimeFormat.prototype.format behavior is specified here:
https://402.ecma-international.org/1.0/#sec-12.3.2
[...]
Note that in point 3., the "minimumIntegerDigits: 2" is absent and FormatNumber.format() returns "3" instead of "03". Al least, that's how I interpret this.
The user-requested format isn't directly used in FormatDateTimePattern. There's actually an earlier step within the Intl.DateTimeFormat
constructor to map the user-requested format to a different format pattern: In InitializeDateTimeFormat, the user-requested format is processed and stored in the formatOptions
variable. formatOptions
is then passed to either BasicFormatMatcher or BestFitFormatMatcher, where formatOptions
is mapped to a pattern supported by the platform. This is where the CLDR data comes into play and the format "yM" is mapped into the pattern string "MM/y". The resolved pattern has the format {year: "numeric", month: "2-digit"}
, which is then later processed by the FormatDateTimePattern operation.
Description
•