We have a history of PRs in ECMA 402 for "small" changes. Here is a list:
https://github.com/tc39/ecma402/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+Normative The PRs often involve changes to reflect web reality / ICU behavior. We are discussing with the ECMA 402 editors on how we want to handle Frank's work, as a PR or as a staged proposal. I am leaning toward PR because this is only extending an existing API schema (Intl.DateFormat) in a way that is fully consistent with other options in that schema. Shane On Thu, May 23, 2019 at 6:43 PM Frank Tang (譚永鋒) <[email protected]> wrote: > > > On Thu, 23 May 2019 at 01:31, Adam Klein <[email protected]> wrote: > >> On Thu, May 23, 2019 at 1:11 AM Frank Tang <[email protected]> wrote: >> >>> Contact emails [email protected],[email protected] Explainer >>> https://github.com/tc39/ecma402/pull/346 >>> >> >> I'd like to better-understand the ECMA 402 process around small additions >> like this (and your other email about "quarter"). Will this become a formal >> proposal (and an attached issue, >> https://github.com/tc39/ecma402/issues/343) the extent of the >> specification process for this feature? Is there a "stage" process for >> these things? >> > > Thank about this point. I actually brought this issue up to ECMA402 chair > sffc@ about should I group them into one proposal or deal with them as > separated PR. And Shane also loop in Daniel about this. Shane is following > up this too. Some of the changes bigger this one, such as the BigInt / > Intl.NumberFormat support went through as a PR and this is not really a > "big new feature" but rather some minor improvement on pre-existing API so > I try to follow the same track. There are several issues all independent > from each other and group them together into one proposal might create > unnecessary dependency (for example, the week of year and week of month has > CLDR/ ICU issues which will take a much longer time to address) and propose > each one of them as individual proposal (so there will be 4) seems too > much. > > Regards, > Frank > >> >> >>> Design docs/spec Specification: https://github.com/tc39/ecma402/pull/346 >>> https://github.com/tc39/ecma402/pull/346 TAG review No TAG review >>> needed since it is part of TC39 ECMA402 Summary Add dayPeriod option to >>> Intl.DateTimeFormat so the caller can format time such as "7 in the >>> morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the >>> evening", "10 at night" (or in Chinese "清晨7時", "上午11時", "中午12時", "下午1時" >>> ,"下午6時" ,"晚上10時") Motivation It enhances the Intl.DateTimeFormat API to >>> match what the developer cal already do in C++ and Java by calling ICU and >>> ICU4J. Without this feature, developer need to either format the quarter in >>> the server or ship a set of day period pattern and hour to day period >>> mapping logic from the server to client to perform such task. Risks >>> Interoperability and Compatibility low. *Firefox*: No public signals >>> *Edge*: No public signals *Safari*: No public signals *Web developers*: >>> No signals Ergonomics No increase of data. All required data already >>> build into ICU. >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature >>> fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? Yes Tests will be added into test262 before we consider shipping it. Link >>> to entry on the Chrome Platform Status >>> https://www.chromestatus.com/features/6520669959356416 >>> >> > > -- > Frank Yung-Fong Tang > 譚永鋒 / 🌭🍊 > Sr. Software Engineer > -- -- 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/CABxsp%3DnvZ1VQ0AQf4ri85QEQBJOxHtsAPUd5r%2ByW%2BaqBr2x3eA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
