Re: Intent to Implement: Add formatRange / formatRangeToParts to DateTimeFormat
Frank Tang
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, faba...@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
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.
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?
Tests under tc39/test262 will includes many tests to test this API.
test/intl402/DateTimeFormat/prototype/formatRange and
test/intl402/DateTimeFormat/prototype/formatRangeToParts
Link to entry on the feature dashboard
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 email when I am ready to enable by default.
Adam Klein
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, faba...@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
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.
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?
Tests under tc39/test262 will includes many tests to test this API.
test/intl402/DateTimeFormat/prototype/formatRange and
test/intl402/DateTimeFormat/prototype/formatRangeToParts
Link to entry on the feature dashboard
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 email when I am ready to enable by default.
--
--
v8-users mailing list
v8-u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.