Hi
On 2026-10-05 15:57, Nick Sdot wrote:
On 22.09.26 22:20, Tim Düsterhus wrote:
following Time\Duration in PHP 8.6, Derick and I created an RFC for
Time\Instant and Time\Clock as the next part of the new date and time
API:
https://wiki.php.net/rfc/time_instant_class
Why would this not become an always bundled `ext/time`?
For the “always enabled” extensions it doesn't really matter *where* the
code is located and the (observable) end result for the user is the same
(except for `ReflectionExtension`). Time\Duration went into ext/date for
simplicity, since timelib is already properly wired into ext/date.
Since this proposed new date/time API will be the successor of the old
date/time API, why not also physically & cleanly separate the new from
the old stuff? `ext/standard` is such a kitchen sink already that I
wonder why modern successors would not live in a more "sensible"
structure. Imagine a (far) future where we could chose to compile PHP
with or without legacy stuff -- clean separation would make this
easier.
It's ext/date, not ext/standard where the API lives. For Time\Duration
we already split off the implementation into a separate and effectively
standalone `php_time.h` header with `php_time.c` and `time_duration.c`
source files, instead of the `php_date.[ch]` kitchen sink.
As far as my understanding of the policy goes, nothing would forbid
making this an extension (see ext/uri)?
That is accurate.
Best regards
Tim Düsterhus
