Hi everyone,
I hope you're all doing well.
I would like to propose a new RFC: intl_date_format().
The main idea behind this is to simplify date formatting across different
calendars (like Persian, Islamic, etc.) without having to go through the
verbose setup of IntlDateFormatter every single time. It's meant to be a
simple, procedural wrapper that makes handling non-Gregorian calendars much
more accessible for everyday tasks.
You can check out the full RFC here:
https://wiki.php.net/rfc/intl_date_format
I’ve ensured the implementation remains consistent with our existing intl
error handling patterns (using E_WARNING and returning false on
failure).
I’m really looking forward to hearing your thoughts, feedback, and any
suggestions you might have to improve this. Thanks for your time and for
all the great work you do!
Best regards,
Sepehr Mahmoudi
Hi everyone,
I hope you're all doing well.
I would like to propose a new RFC:
intl_date_format().The main idea behind this is to simplify date formatting across different calendars (like Persian, Islamic, etc.) without having to go through the verbose setup of
IntlDateFormatterevery single time. It's meant to be a simple, procedural wrapper that makes handling non-Gregorian calendars much more accessible for everyday tasks.You can check out the full RFC here:
https://wiki.php.net/rfc/intl_date_formatI’ve ensured the implementation remains consistent with our existing
intlerror handling patterns (usingE_WARNINGand returningfalseon failure).I’m really looking forward to hearing your thoughts, feedback, and any suggestions you might have to improve this. Thanks for your time and for all the great work you do!
No.
The procedural API is ill defined and should NOT be expanded.
Constructing an object is also not that difficult.
It would be a good idea for you to step back from the mailing list and stop proposing RFCs every 2 days as you are frankly spamming the mailing lists with proposals that have no value and waste everyone's time.
I can understand the desire to contribute back to PHP, but shotgunning proposals in the hope that one will stick is not an approach that will net you any sympathy, as you have clearly used up any sympathy people have had for you over the last few weeks.
Or put more plainly, I will personally take the time to write a formal RFC to ban you from the project if you continue spamming the mailing list.
I'll allow a single reply to this email before taking action.
Sincerely,
Gina P. Banyard
Hi Sepehr
Can you please explain the advantage you see in using
your proposed API instead of:
$formatter = new IntlDateFormatter(
'fa_IR@calendar=persian',
IntlDateFormatter::NONE,
IntlDateFormatter::NONE,
'UTC',
IntlDateFormatter::TRADITIONAL,
'yyyy/MM/dd',
);
echo $formatter->format(strtotime('2026-09-27 UTC')); // ۱۴۰۵/۰۷/۰۵
To justify the addition into the extension?
BR,
Weilin Du
در تاریخ دوشنبه ۲۸ سپتامبر ۲۰۲۶، ۱۴:۵۱ Weilin Du weilin-du@qq.com نوشت:
Hi Sepehr
Can you please explain the advantage you see in using
your proposed API instead of:$formatter = new IntlDateFormatter( 'fa_IR@calendar=persian', IntlDateFormatter::NONE, IntlDateFormatter::NONE, 'UTC', IntlDateFormatter::TRADITIONAL, 'yyyy/MM/dd', ); echo $formatter->format(strtotime('2026-09-27 UTC')); // ۱۴۰۵/۰۷/۰۵To justify the addition into the extension?
BR,
Weilin Du
Hi Weilin,
Thank you for bringing this up. That is a very fair and essential question.
The primary motivation behind intl_date_format() is developer ergonomics,
reducing cognitive boilerplate, and internal optimization:
-
Boilerplate & Ergonomics:
UsingIntlDateFormatterdirectly requires configuring up to 6 parameters
(datetype, timetype, calendar constants, pattern, timezone, and locale
syntax). For standard web use cases—such as quickly outputting a
localized/calendar-aware date (e.g., Jalali or Hijri in an API response or
UI template)—developers frequently find the existing API overly verbose and
unintuitive. A simple, procedural wrapper mirrors the simplicity developers
are used to withdate(), but with ICU's full calendar capabilities. -
C-level Caching Potential:
In userland, repeatedly instantiatingIntlDateFormattercarries
noticeable instantiation overhead unless developers implement their own
pooling/singleton mechanisms. A native C implementation can optimize
pattern/calendar cache instances internally, offering better out-of-the-box
performance for batch-rendering dates. -
Addressing Gaps in the Draft:
Based on your feedback and further reflection, I recognize that the current
draft should be refined before proceeding:
- Support for
DateTimeInterface(allowing DateTime/DateTimeImmutable as
the$dateargument). - An explicit
$timezoneparameter (defaulting to the date object's
timezone ordate_default_timezone_get()). - Modern PHP 8 error semantics (throwing
ValueError/IntlException
instead of emittingE_WARNINGand returningfalse). - Better locale/calendar integration (e.g., accepting BCP-47 / ICU locale
keywords seamlessly).
Would such adjustments make the API justifiable from a maintainer's
perspective, or would you prefer exploring a static convenience method on
IntlDateFormatter (e.g., IntlDateFormatter::formatQuick(...)) instead
of a procedural function?
I'd really appreciate your thoughts on this direction.
Best regards,
Sepehr
Hi, internals
This is clearly AI-generated slop
Regards,
Pedro Veloso
در تاریخ دوشنبه ۲۸ سپتامبر ۲۰۲۶، ۱۷:۵۶ Pedro Veloso <
contatopedrohalves@gmail.com> نوشت:
Hi, internals
This is clearly AI-generated slop
Regards,
Pedro Veloso
Thanks for the feedback, Pedro. I am currently focused on the
implementation details and unit tests. If there are any specific technical
flaws regarding the proposed API design or C-level implementation, I would
appreciate your insights on those
Le 28/09/2026 à 17:04, سپهر محمودی a écrit :
در تاریخ دوشنبه ۲۸ سپتامبر ۲۰۲۶، ۱۷:۵۶ Pedro Veloso
contatopedrohalves@gmail.com نوشت:Hi, internals This is clearly AI-generated slop Regards, Pedro Veloso
Thanks for the feedback, Pedro. I am currently focused on the
implementation details and unit tests. If there are any specific
technical flaws regarding the proposed API design or C-level
implementation, I would appreciate your insights on those
Hi Sepehr. You should stop using AI-written emails like that, this feels
rude, and you have also been told several times that many RFCs you are
proposing are not worth the effort.
I suggest you to stop emailing "PHP Internals" and find community
networks (Slack, Discord, IRC, etc.) to discuss your ideas there before
submitting them to the already busy PHP Internals RFCs reviewers.
I suggest you to stop emailing "PHP Internals" and find community networks (Slack, Discord, IRC, etc.) to discuss your ideas there before submitting them to the already busy PHP Internals RFCs reviewers.
This has been enforced on the mailserver after consultation off list.
The email address has been blocked from sending emails to the php.net domain, wiki access has been withdrawn, and the email has been unsubscribed from the internals list.
cheers
Derick
...
Hello dear Sepher.
I may personally understand that you really want to be considered as a PHP internal contributor. It can be considered as a very high distinction in any academic or career pursuit.
However, your emails and proposal sounds like AI generated content to quickly enter in the circle of "elite" programmers without even considering that your proposal doesn't bring any new value on the table.
I, personally, developed in WordPress for so long that, on a very busy day, I understood that using procedural function approach was just not a good idea. And if you have read the proposal from PHP8.5, you can observe new features added on PHP object oriented programming and function oriented programming with the "|>", which simply are better solution for coding in general compared to procedural function (unless you code in C, which is the default coding style).
Please, stop messaging the PHP internal group. First get your idea approved by a real community of PHP developers that struggle with the kind of problems your RFC proposals are dealing with. Else you are slowly, but greatly, demonstrating a lack of commitment to quality improvement of PHP internals, either due to lack of knowledge or lack of desire to do so but still keep pushing what seems like AI generated content for the sake of being popular.
In this group, from what I understand, serious business to get PHP greater is in place. And the group is very kind enough to repeatedly expose your misconception, without banning since day 1 (and to answer to my personal questions about PHP internals, thanks to anyone for that, I appreciate it a lot).
Kind regards,
David Maye.
El 27/09/2026 21:17 سپهر محمودی sepehrphpr@gmail.com escribió:
Hi everyone,
I hope you're all doing well.
I would like to propose a new RFC:
intl_date_format().The main idea behind this is to simplify date formatting across different calendars (like Persian, Islamic, etc.) without having to go through the verbose setup of
IntlDateFormatterevery single time. It's meant to be a simple, procedural wrapper that makes handling non-Gregorian calendars much more accessible for everyday tasks.You can check out the full RFC here:
https://wiki.php.net/rfc/intl_date_formatI’ve ensured the implementation remains consistent with our existing
intlerror handling patterns (usingE_WARNINGand returningfalseon failure).I’m really looking forward to hearing your thoughts, feedback, and any suggestions you might have to improve this. Thanks for your time and for all the great work you do!
Best regards,
Sepehr Mahmoudi