Closed Bug 1496584 Opened 2 years ago Closed 3 months ago

Implement Intl.DateTimeFormat.prototype.formatRange and .formatRangeToParts

Categories

(Core :: JavaScript: Internationalization API, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox80 --- fixed

People

(Reporter: jorendorff, Assigned: anba)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-needed, parity-chrome)

Attachments

(6 files, 1 obsolete file)

Keywords: dev-doc-needed
QA Contact: jwalden+bmo
QA Contact: jwalden+bmo

This is now Stage 3, and Chrome has implemented it, planning on shipping soon.

Uploaded a draft patch, which due to the reasons outlined in comment #2, can't land.

Fixes for the linked issues are landing in ICU 67, which is being released today.

Is there anything else blocking the formatRange proposal in SpiderMonkey?

I've performed some cursory testing and didn't find any obvious blockers. I did find two ICU bugs [1,2], but those are probably not hard blockers.

[1] Mismatched hour skeleton and hc Unicode extension keys result in different outputs depending on whether or not a range is present.
[2] ICU doesn't seem to fully implement step 2 from https://unicode.org/reports/tr35/tr35-dates.html#intervalFormats, for example "de.xml" contains

<intervalFormatItem id="H">
  <greatestDifference id="H">HH–HH 'Uhr'</greatestDifference>
</intervalFormatItem>

but ICU doesn't seem to use this interval format when the hour skeleton character is "k" instead of "H".

That way this function can be reused for the date range formatting.

Assignee: nobody → andrebargull
Status: NEW → ASSIGNED

Move the locale computation into a separate function, so we can reuse it in
a later patch.

Depends on D79318

Later patches will add the interval formatter, whose size also needs to be
tracked.

Depends on D79319

The date interval formatter requires a skeleton for its input, so we need to
store the skeleton string in addition to the pattern string. Prepare for this
change by splitting the skeleton computation from toBestICUPattern.

Depends on D79320

Attachment #9155982 - Attachment description: Bug 1496584 - Part 2: Split DateTimeFormatLocale from NewUDateFormat. r=jwalden! → Bug 1496584 - Part 3: Split DateTimeFormatLocale from NewUDateFormat. r=jwalden!
Attachment #9155983 - Attachment description: Bug 1496584 - Part 3: Rename the estimated-size member of DateTimeFormatObject. r=jwalden! → Bug 1496584 - Part 4: Rename the estimated-size member of DateTimeFormatObject. r=jwalden!
Attachment #9155984 - Attachment description: Bug 1496584 - Part 4: Split skeleton computation from toBestICUPattern. r=jwalden! → Bug 1496584 - Part 5: Split skeleton computation from toBestICUPattern. r=jwalden!
Attachment #9078708 - Attachment is obsolete: true
Pushed by dluca@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ce4987951537
Part 1: Move FormattedValueToString into CommonFunctions.h. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/509364db7c0d
Part 2: Include previously disabled date-interval formatters. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/02cdd5e863ae
Part 3: Split DateTimeFormatLocale from NewUDateFormat. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/f354edbe8be6
Part 4: Rename the estimated-size member of DateTimeFormatObject. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/25d650de6d6c
Part 5: Split skeleton computation from toBestICUPattern. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/373d4c8b47cd
Part 6: Add support for Intl.DateTimeFormat.prototype.formatRange proposal. r=jwalden

Given the workarounds for the ICU issues in the patch, is there a need for this to be nightly-only any more? The patches landed with that configuration, but it's not clear to me what prevents a followup bug making this not merely nightly-only at this point.

Flags: needinfo?(andrebargull)

The spec has two issues I'd like to see resolved before letting this feature ride to release:

  1. There's https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/21 which means the spec as-is doesn't do the correct thing at all. I've added some comments how it could be fixed, but nobody seems to have looked into that one yet.
  2. And I'm not sure how people feel about https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/22. Proposal champions and reviewers need to chime in there, too.
Flags: needinfo?(andrebargull)
Blocks: 1653024
You need to log in before you can comment on or make changes to this bug.