Re: [RFC] IntlRelativeDateTimeFormatter

On Fri, 7 Aug 2026 at 19:49, Weilin Du <weilin-du@qq.com> 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