Intend to Ship: Add calendar options/patterns and other calendars

16 views
Skip to first unread message

Frank Tang

unread,
Oct 2, 2019, 4:12:12 PM10/2/19
to v8-...@googlegroups.com, v8-users, Adam Klein, blink-dev, Mathias Bynens, Frank Yung-Fong Tang, Shane Carr, Nebojša Ćirić, Jakob Kummerow
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 #2381 #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.

Frank Tang

unread,
Oct 3, 2019, 3:40:54 PM10/3/19
to v8-...@googlegroups.com, v8-users, Adam Klein, blink-dev, Mathias Bynens, Frank Yung-Fong Tang, Shane Carr, Nebojša Ćirić, Jakob Kummerow
To clarify these 3 PRs are considered by both ECMA402 subcommittee and TC39 as "Stage 3"

I forgot to include the previous "Intend to Implement" link. Here it is.


These three PRs was once only 1 PR and later got split into 3 PRs. so the original I2I cover all of them.

Chris Harrelson

unread,
Oct 3, 2019, 4:06:52 PM10/3/19
to Frank Tang, v8-...@googlegroups.com, v8-users, Adam Klein, blink-dev, Mathias Bynens, Frank Yung-Fong Tang, Shane Carr, Nebojša Ćirić, Jakob Kummerow
Also, v8 intents do in fact go through the Blink API owners process. Please don't ship until there are 3 LGTMs.

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8iJdVbwNWBhdU-1HiNVqp4pQm_C1CfrF6D%3DHvWWPdN9w%40mail.gmail.com.

Frank Tang

unread,
Oct 3, 2019, 4:19:45 PM10/3/19
to Chris Harrelson, v8-...@googlegroups.com, v8-users, Adam Klein, blink-dev, Mathias Bynens, Frank Yung-Fong Tang, Shane Carr, Nebojša Ćirić, Jakob Kummerow

Sorry, I forgot to remove "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." when I copy and paste from my old I2S email. It should be 
Reply all
Reply to author
Forward
0 new messages