Happy to see this moving forward! A note, below, on the (new-to-V8) intent process.
On Mon, May 6, 2019 at 10:48 AM Frank Tang <ft...@chromium.org> wrote: > cc v8-users@ > > On Fri, May 3, 2019 at 7:58 PM Frank Tang <ft...@chromium.org> wrote: > >> opps. forgot to include the blink-dev@ in the To field. >> >> On Fri, May 3, 2019 at 7:51 PM Frank Tang <ft...@chromium.org> wrote: >> >>> Title: Intent to Implement: 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) >>> >>> Design doc/Spec >>> >>> https://goo.gl/PGUQ1d >>> >>> Summary >>> >>> Add two new functions to Intl.DateTimeFormat.prototype - formateRange >>> and formatRangeToParts to formate the range of two dates in a given locale. >>> >>> Motivation >>> >>> It's common for websites to display date intervals or date ranges to >>> show the span of an event, such as a hotel reservation, the billing period >>> of a service, or other similar uses. In order to implement this, websites >>> often use localization libraries, such as Google Closure, to format the >>> date range, or they may simply resort to formatting both dates >>> independently. >>> >>> If following the second alternative, web developers may encounter >>> problems such as repeating fields that are common between the two dates, >>> inappropriate order of the dates for the locale or using an incorrect >>> delimiter for the locale. This API provide locale sensitive formatting >>> avoid such problem. >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> This is a new API so it should have no risk in term of interoperability >>> and compatibility. >>> >> Being a new API doesn't make something immune from interop or compat risk. Some things generally listed in this section are stage at TC39 and public statements or implementation status from other browser vendors. See https://sites.google.com/a/chromium.org/dev/blink?pli=1#TOC-Policy-for-shipping-and-removing-web-platform-API-features for more details. 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. >>> >>> Debuggability >>> >>> Nothing special. >>> >>> >>> 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> >>> ? >>> >>> 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> >>> >>> >>> >>> Link to entry on the feature dashboard <https://www.chromestatus.com/> >>> >>> https://www.chromestatus.com/feature/5077134515109888 >>> >>> Requesting approval to ship? >>> >>> “No”. The feature is behind a runtime flag harmony_intl_date_format_range >>> and I will later send an Intent to Ship >>> <https://docs.google.com/a/chromium.org/document/d/1EyRTYnF2bmgqwYQQTDs2R2BT3ZSx29iPCFKTQiS_37o/edit> >>> email when I am ready to enable by default. >>> >> -- > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- -- 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/CAEvLGcKWa0F5KG3yPtgBBT5UoX9x5sSXfRVuy3w%3DcSYkeki%2BJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
