LGTM2 /Daniel
On Thursday, 3 October 2019 22:19:46 UTC+2, Frank Tang wrote: > > > 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 > > " > > Requesting approval to ship? > > Yes. > > " > > On Thu, Oct 3, 2019 at 1:06 PM Chris Harrelson <[email protected] > <javascript:>> wrote: > >> Also, v8 intents do in fact go through the Blink API owners process. >> Please don't ship until there are 3 LGTMs. >> >> LGTM1 >> >> On Thu, Oct 3, 2019 at 12:40 PM Frank Tang <[email protected] >> <javascript:>> wrote: >> >>> 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. >>> >>> >>> https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/numberingSystem%7Csort:date/blink-dev/HFOWIjSBKWQ/XZnslmWsAQAJ >>> >>> These three PRs was once only 1 PR and later got split into 3 PRs. so >>> the original I2I cover all of them. >>> >>> >>> On Wed, Oct 2, 2019 at 1:11 PM Frank Tang <[email protected] >>> <javascript:>> wrote: >>> >>>> 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. >>>> >>> -- >>> 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 [email protected] <javascript:>. >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8iJdVbwNWBhdU-1HiNVqp4pQm_C1CfrF6D%3DHvWWPdN9w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/98c94032-41d7-496a-b2c2-59697a4b11bc%40chromium.org.
