IntlRelativeDateTimeFormatter proposal

Voting open until 2026-10-22 00:00 UTC; not accepted. The official RFC index lists the RFC (version 0.4.1, dated 2026-08-09, author Weilin Du) as voting, and its target is PHP 8.7. The author announced the start of voting at 16:14 UTC on 7 October, after a page edit at 16:10 UTC. The vote ends on 2026-10-22 at 00:00 UTC. That is earlier than the start the author had given: an intent-to-vote message on 5 October and a voting section added at 10:02 UTC on 7 October both said 2026-10-08 00:00 UTC. The edited voting section now gives only the end time. There is one primary question, "Add IntlRelativeDateTimeFormatter as described to ext/intl?", which needs a 2/3 majority. When the page was checked at about 10:02 UTC on 14 October the poll showed 18 yes, 0 no and 0 abstain (7–0–0 on 7 October). That is an interim count, not a result.

Page header updated on 14 October: an edit at 07:02 UTC ("update status") changed the header from Status: Under Discussion to Status: Voting, so the page now agrees with the index. The header still says Voting thread: TBD. The discussion thread began in August. Acceptance and any release are separate events from the vote.

What is proposed

A new final class IntlRelativeDateTimeFormatter in ext/intl, wrapping ICU's URelativeDateTimeFormatter C API (stable since ICU 57, and ext/intl already requires ICU 57.1 or newer). It would produce strings such as "yesterday", "in 3 days" or "5 minutes ago" for a locale. The class and three pure (unbacked) enums would live in the global namespace:

• IntlRelativeDateTimeFormatterStyle (Long, Short, Narrow);
• IntlRelativeDateTimeFormatterCapitalization (None, MiddleOfSentence, BeginningOfSentence, UiListAndMenu, Standalone);
• IntlRelativeDateTimeFormatterUnit (Year through Second, plus Sunday through Saturday).

The constructor takes ?string $locale (where null means the default intl locale), a style, a capitalization context and an optional NumberFormatter. The formatter keeps the supplied NumberFormatter, so later configuration changes to it affect later output. Methods:

• format(int|float $offset, $unit) uses a text form when the locale has one ("yesterday", "last week") and otherwise falls back to a numeric form;
• formatNumeric() always uses the numeric form ("1 day ago", "in 1.5 hours");
• combineDateAndTime(string $relativeDate, string $time) joins two already formatted strings with the locale's date-time separator. It does not parse or validate them;
• getErrorCode() and getErrorMessage() follow the usual ext/intl error conventions. ICU failures return false, or throw if intl.use_exceptions is on. A wrong enum argument always throws TypeError.

The RFC does not change IntlDateFormatter::RELATIVE_*, which formats a concrete date. No procedural aliases or integer constants are added. The backward-compatibility section notes that the four new global names could conflict with userland declarations while intl is loaded. The changelog records changes made in response to feedback from Tim Düsterhus and others, such as adopting the three pure enums on 2026-09-19.

Limitations

The RFC page is inconsistent about the implementation. Its header links php-src PR #23514, but "Patches and Tests" says "TBD". The PR was not inspected in this cycle. The example output strings depend on ICU locale data and version. Nothing here is available in released PHP. Related: intl_date_format() proposal, a separate ext/intl draft.