Implement RelativeTimeFormat

[sffc]

ECMA-402 includes RelativeTimeFormat, a formatter that supports relative durations (such as "1 hour ago").

Under the hood, RelativeTimeFormat relies on fairly straightforward CLDR data described in UTS 35.

The main open question with RelativeTimeFormat in ICU4X is whether it should be merged in with DurationFormat (#801) as an alternative style, rather than being implemented as its own API. I tend to think that RelativeTimeFormat is small enough in scope that it should be implemented on its own, although more advanced formatting (such as mixed units) could be at some point added to DurationFormat.

[zbraniecki]

I think the main difference between relativetime and duration is that duration represent intervals while relative time represents, well, relative time. I understand that you can reason about relative time as a duration between a given moment and now, but I think this is not how humans think. Relative time APIs are intended to help people understand contextual time from their relative position, while durations are much more abstract. The canonical abstraction of duration is a length of a movie, or flight, while a canonical abstraction of relative time is a point in time that is meaningful in relationship to now.

I can understand how internal logic of those two can be unified, but I think that the API should be kept separate to allow for optimal shape for the purpose those two serve, and that purpose I think is distinct.

[zbraniecki]

(I recognize that my mental model is easy to challenge - "5 hours before event X" is a relative time with anchor not being "now", but I still think it is conceptually distinct from "an event took 5 hours between Y and X".)

[sffc]

The suggestion to merge the two originally came from https://github.com/tc39/proposal-intl-duration-format/issues/29#issuecomment-661276281. The mental model is that RelativeTimeFormat is just a duration formatter, but with an anchor time of "now". A third style, as you noted, would be "duration relative to event X." So your styles end up being:

• The event lasted 5 hours 30 minutes (absolute duration)
• The event started 5 hours 30 minutes ago (relative to now)
• The event started 5 hours 30 minutes after the guests arrived (relative to event)

[zbraniecki]

My claim is that while underlying logic is similar and may even be shared, the ergonomic API is going to be significantly different if designed optimally for the use case. If we forcefully coalesce those two I'm concerned well end up with exposing awkward API design for one to match the needs of the other.

[zbraniecki]

@rxaviers described the issues around discrete relative times in context of ECMA-402. I think we should tackle that in ICU4X - https://github.com/rxaviers/relative-time

[sffc]

2021-06-24:

• Implement RelativeTimeFormat in conformance with ECMA-402
• @sffc - Like #800, consider making RelativeTimeFormat a sub formatter of DurationFormat (#801)
• Consider naming the class RelativeDurationFormat instead of RelativeTimeFormat
• Evaluate @zbraniecki's suggestions above, but don't scope creep RelativeTimeFormat

[pdogr]

A transformer for relative time component was added in #2822

[sffc]

Discussion about the API surface:

• @robertbastian - Seems like we want something to automatically choose the correct unit.
• @younies - Can we access the output unit from this? I think clients want to access the output as parts. It could alternatively be another API like a relative time converter.
• @sffc - We may want a higher-level class that does lots of types of duration formatting. "-3hr" and "3 hours ago" are two different styles. I don't want to impose that on the lower-level class.
• @robertbastian - We should consider a different class name.
• @younies - (re-iterating support for format to parts)
• @Manishearth - The third kind of format ("last Tuesday") needs to be a different API because it requires more data and user preferences. For example, "next weekend" means different things to different people.
• @sffc - Naming suggestions?
• @robertbastian - RelativeTimeUnit, RelativeTimeUnitsFormatter, RelativeTimeAtomsFormatter
• @sffc - I'm not clear on the use case for fancy interpretation of the output, because this is just a pass-through.
• @younies - SimpleRelativeTimeFormatter, NaiveRelativeTimeFormatter
• @echeran - RelativeTimeWithUnitsFormatter
• @Manishearth - We could delay the naming discussion until we have the fuller picture designed
• @sffc - Should we release the low-level thing as stable before we design the high-level thing?
• @robertbastian - We might box ourselves in if we stabilize it sooner

[sffc]

This issue is in the 1.2 Blocking milestone. Let's decide what needs to be done for 1.2 or whether to move the whole issue to a different milestone.

[sffc]

To clarify: we are just blocking on a proposal for the higher-level RelativeTimeFormatter API. We don't want to release parts of RelativeTimeFormatter without the full design.

[robertbastian]

https://docs.google.com/document/d/16Js0nBEntjkKZsFWGBjjRrqjD3LRkbFAcKjWhJT4_6M/edit?disco=AAAA1bvCGxU