[PHP-DEV] [VOTE] [RFC] IntlRelativeDateTimeFormatter

Hi internals!

I am excited to announce the start of the voting of
my latest RFC on the international extension!

discussion link: https://externals.io/message/132187
RFC: https://wiki.php.net/rfc/reldateformatter

The voting process will end at 2026-09-29 11:14:40 UTC.

Thanks,
Weilin Du

Hi

On 2026-09-15 13:18, Weilin Du wrote:

I am excited to announce the start of the voting of
my latest RFC on the international extension!

It's debatable if the latest changes in response to my email constitute a major or a minor change regarding the cooldown. However there was also no email that changes *were* made to the RFC text (only that some were *planned*), which is why I didn't recheck the RFC before the vote - and the intent to vote expired.

Content-wise I also don't agree with the decision to keep using untyped constants instead of enums, but didn't have the time to actually think this through or read the RFC in-depth.

For these reasons I voted against the RFC.

Best regards
Tim Düsterhus

Hi,

It’s debatable if the latest changes in response to my email constitute
a major or a minor change regarding the cooldown. However there was also
no email that changes were made to the RFC text (only that some were
planned), which is why I didn’t recheck the RFC before the vote - and
the intent to vote expired.

I think you’ve read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it because
you don’t send more email to the thread. Maybe I don’t have the English
skill to make it clear about what is planned and made.

Given this misunderstanding yes I will threat this as a major change and
revert the voting process.

Content-wise I also don’t agree with the decision to keep using untyped
constants instead of enums, but didn’t have the time to actually think
this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree on this.
However, using untyped constants is a convention to the extension. Every other
classes in the extension don’t use enums. I’d suggest to add this in the future
scope so a extension-wide RFC can revisit this topic later. I don’t want to make
this new class special to others at the sake of consistency.

Further, using namespaces is also preferred here.

For these reasons I voted against the RFC.

Please let me know if you have further suggestions. After resolving it, I will
announce the cooldown period again. There is no need to rush anyways :slight_smile:

Weilin Du

Hi

On 2026-09-15 14:02, Weilin Du wrote:

I think you've read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it because
you don't send more email to the thread. Maybe I don't have the English
skill to make it clear about what is planned and made.

No, I hadn't taken another look at the RFC yet. I also made it clear that I had not given it much thought (due to time constraints). But my schedule should not be a blocker for RFCs to proceed.

> Content-wise I also don't agree with the decision to keep using untyped 
> constants instead of enums, but didn't have the time to actually think 
> this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree on this.

From what I see not much discussion has happened on that topic. It's basically just David suggesting it (and me previously suggesting it in private) and you declining the suggestion. I think we can find a reasonable middle-ground that makes use of enums, while not precluding a future redesign of the ext/intl API. I'll send those to the discussion thread to keep it in a single place.

Best regards
Tim Düsterhus

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۳:۰۴ Tim Düsterhus <tim@bastelstu.be> نوشت:

Hi

On 2026-09-15 14:02, Weilin Du wrote:

I think you’ve read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it
because
you don’t send more email to the thread. Maybe I don’t have the English
skill to make it clear about what is planned and made.

No, I hadn’t taken another look at the RFC yet. I also made it clear
that I had not given it much thought (due to time constraints). But my
schedule should not be a blocker for RFCs to proceed.

>
Content-wise I also don’t agree with the decision to keep using
untyped 
>
constants instead of enums, but didn’t have the time to actually think 
>
this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree
on this.

From what I see not much discussion has happened on that topic. It’s
basically just David suggesting it (and me previously suggesting it in
private) and you declining the suggestion. I think we can find a
reasonable middle-ground that makes use of enums, while not precluding a
future redesign of the ext/intl API. I’ll send those to the discussion
thread to keep it in a single place.

Best regards
Tim Düsterhus


Hi Tim,

Thanks for bringing this up. I completely welcome finding a reasonable middle-ground.

My long-term plan is indeed to actively contribute to ext/intl (especially aiming for PHP 8.7, where we can systematically modernize the extension with proper namespaces, enums, and cleaner error handling).

I’d be glad to see your proposed middle-ground in the main discussion thread, and we can definitely work together to align it so it fits both the current RFC requirements and the future ext/intl roadmap.

Best regards,
Sepehr