These three ECMA402 PRs are intertwined and need to be considered to ship together instead of three different one:
#175 Add calendar and numberingSystem options #349 Allow calendar to determine choice of pattern #351 Permit relatedYear and yearName in output Spec https://github.com/tc39/ecma402/pull/175 https://github.com/tc39/ecma402/pull/349 https://github.com/tc39/ecma402/pull/351 Summary All three ECMA402 PRs reach consensus from both ECMA402 committee late Sept and TC39 in Oct. These three PRs make the pre-existing Intl.DateTimeFormat to specify different "calendar" via option (instead of appending the calendar as "-u-ca-$calendar" in locale) and make the Intl.DateTimeFormat choose the pattern accordingly. It also change the formatToParts method to output "relatedYear" or "yearName" type for some non-gregorian calendar (such as Chinese calendar) while both the Chinese calendar year name and the gregorian year name are displayed based on the pattern. It also let Intl.DateTimeFormat and Intl.NumberFormat take numberingSystem from options (instead of appending "-u-nu-$numberingSystem" in locale). Example let o = new Intl.DateTimeFormat("en" , { calendar: "chinese", year: "numeric" });console.log(o.format(Date.now())); // "2019(ji-hai)"console.log(o.formatToParts(Date.now())); // [{type: "relatedYear", value: "2019"}, // {type: "literal", value: "("}, // {type: "yearName", value: "ji-hai"}, // {type: "literal", value: ")"}] let n = new Intl.NumberFormat("en" , { numberingSystem: "thai" });console.log(n.format(1234567890)); // "๑๒๓,๔๕๖,๗๘๙" Interoperability and compatibility risk The options "numberingSystem" added to Intl.DateTimeFormat and Intl.NumberFormat is already supported by Intl.Locale and Intl.RelativeTimeFormat with the same meaning. The options "calendar" added to Intl.DateTimeFormat is already supported by Intl.Locale with the same meaning. The risk to break pre-existing javascript code is low. - Firefox: No public signals - Edge: No public signals - Safari:No public signals - Web Developers:No signals Is this feature fully tested? Yes; our implementation passes our own V8 tests for all the features. test/intl/number-format/check-numbering-system.js test/intl/number-format/constructor-numberingSytem-order.js test/intl/date-format/check-numbering-system.js test/intl/date-format/check-calendar.js test/intl/date-format/constructor-calendar-numberingSytem-order.js test/intl/date-format/related-year.js test/intl/regress-9786.js test/intl/regress-9787.js test/intl/regress-9788.js test/intl/regress-966285.js Also test262 tests (more to come this week #2379 <https://github.com/tc39/test262/pull/2379> #2381 <https://github.com/tc39/test262/pull/2381> #2383 <https://github.com/tc39/test262/pull/2383>) intl402/NumberFormat/numbering-system-options intl402/DateTimeFormat/numbering-system-calendar-options Tracking bug https://crbug.com/v8/9154 https://crbug.com/v8/9155 Link to entry on the Chrome Platform Status dashboard https://www.chromestatus.com/features/5440249461211136 Requesting approval to ship? Yes. Note that since this is a V8/JS feature, this post is just an FYI to blink-dev — no signoff from Blink API owners is required. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAOcELL_8Syp%2B21ZtM_%3Di2B1e%2B_CXaASUYfuTFh17i7xn995rYQ%40mail.gmail.com.
