Intend to ship for Chrome m76
Title: Intent to Ship: Add formatRange / formatRangeToParts to DateTimeFormat Contact emails ft...@chromium.com, fabal...@chromium.com Explainer https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/ (notice the spec is already advanced into stage 3 in tc39 March 2019 meeting but the latest version has not bump the version from 2 to 3 yet) Spec https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/ Design Doc https://goo.gl/PGUQ1d Why the tag review process is being skipped: JavaScript features do not need to go through a TAG review, as they already get significant scrutiny as part of the TC39 staging process <https://tc39.github.io/process-document/>. Summary Add two new functions to Intl.DateTimeFormat.prototype - formateRange and formatRangeToParts to formate the range of two dates in a given locale. Link to “Intent to Implement” blink-dev discussion https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/DateTimeFormat%7Csort:date/blink-dev/WTAjjcXaraA/osqw0lCpBAAJ Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Demo link https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange Debuggability Nothing special. Risks Interoperability and Compatibility This is a new API which agreed in TC39 meeting as a Stage 3 proposal. Engineer from Firefox team is supporting this proposal and the development is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1496584 Ergonomics The performance of constructing the Intl.DateTimeFormat could be slower if we create the underline icu DateIntervalFormatter. To avoid such performance issue we identified, currently we plan to lazy initialize the required DateIntervalFormatter upon the first call to the formatRange or formateRangeToParts and cache the value afterward. This approach avoid such performance impact. Activation Web developers could use the API immediately upon our shipment, based on the usage of previous well supported Intl.DateTimeFormat object. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? Link to test suite results from wpt.fyi. Tests under tc39/test262 will includes many tests to test this API. test/intl402/DateTimeFormat/prototype/formatRange <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRange> and test/intl402/DateTimeFormat/prototype/formatRangeToParts <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRangeToParts> Testing Status (since the feature is currently behind a flag, the breakage, which does not include the flag turning on is high. Once shipped, with the flag turn on by default, the passing rate will turn to 100%) https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRange https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRangeToParts Entry on the feature dashboard <http://www.chromestatus.com/> https://www.chromestatus.com/feature/5077134515109888 -- -- 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/CAOcELL9mCNtM745fqWcVMwv1_JNZD0t7z%3DzDihbMiziOLHwOUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
