Re: [PHP-DEV] [RFC] IntlRelativeDateTimeFormatter

On Fri, 7 Aug 2026 at 19:49, Weilin Du <[email protected]> wrote:
>
> Hi Ignace, David,
>
> Thanks for the feedback. IMHO I tend to not accept Duration object as a parameter.
>
> IntlRelativeDateTimeFormatter formats a caller-selected offset and unit. Time\Duration
> represents stopwatch time as seconds and nanoseconds. This cause a huge amount of
> issue which immediately comes into my head when thinking of this.
>
> The API looks like
>
> $fmt->format(3, UNIT_DAY);    // in 3 days
> $fmt->format(2, UNIT_MONTH);  // in 2 months
> $fmt->format(-1, UNIT_SUNDAY);// last Sunday
>
> If we are now accepting Durations, they look like
>
> Time\Duration::fromMinutes(90)
>
> We don't know how to deal with 90 minutes here. It can be 90 minutes or 1.5 hour.
>
> Nevertheless, what about weekdays? things like UNIT_SUNDAY are not durations.
> Not to mention months, quarters, and years need calendar context.
>
> For enums and namespaces: I kept class constants and the global Intl* class name to stay
> consistent with the existing ext/intl API, such as IntlDateFormatter, IntlListFormatter
> IntlNumberRangeFormatter, and IntlDatePatternGenerator. I don't want to make
> IntlRelativeDateTimeFormatter somehow special here just because this is added later.
> I agree that enums and namespaces would be nicer in isolation, *indeed*. But,
> introducing them for only this one formatter would make the API inconsistent with the rest
> of ext/intl.
>
> For the second argument of ureldatefmt_open(): the initial implementation will pass NULL,
> so ICU uses the default number formatter for the selected locale. *This is intended.*
> Exposing a custom NumberFormatter is possible future scope, but it needs extra care
> because ICU adopts ownership of the supplied UNumberFormat, so PHP would need to
> clone the underlying formatter before passing it to ICU.

Well I guess you have time until next release to try out the value of this.
>
> What do you think?
>
> Cheers,
> Weilin