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 <chris...@chromium.org> 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 <ft...@chromium.org> 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 <ft...@chromium.org> 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 blink-dev+unsubscr...@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 >> <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-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/CAOcELL9GtCfEtoNhM7bHACDkSHB%2Bnno0b82tVjyarFa_joy-_A%40mail.gmail.com.
