Hi
On 2026-09-22 16:54, Andreas Heigl wrote:
Later on though you are mentioning that "Following the lead of
virtually all programming languages and operating systems, leap seconds
are ignored."
Is that only with relation to the Iso8601 strings? Or is that a general
shortcoming?
Leap seconds are treated as non-existent as an integral part of the
class design. Operating systems, in particular Unix-based systems as the
arguably most common runtime environment of PHP, don't expose leap
seconds in their time retrieval APIs and pretend very hard that leap
seconds don't exist, either by “halting the clock” for 1 second, by
repeating the second, or by smearing the leap second over a larger
time-frame of “slightly more than a second”-seconds (e.g. across the
preceding 1000 seconds as proposed by UTC-SLS).
Trying to support leap seconds in PHP when the operating system does not
would mean that PHP would need to keep its own list of when a leap
second should have occurred and would require users to actually update
PHP to get correct information (which is something that most certainly
won't happen).
It would necessarily also mean that the difference between two Instant’s
->getUnixTimestamp() values would differ from the duration returned by
`until()` and that two Instants with the same Unix timestamps might
compare unequal.
Given that virtually everyone ignores leap seconds and given that there
hasn't been one for the past 10 years and there are plans to abolish
them by 2035, I don't think it is useful to make PHP in any way special.
This would just invite bug reports from confused users.
So no shortcoming, intentional and deliberate design decision. The
“unique point on the timeline” phrasing is to establish a reasonable
mental model of why Instants don’t have a timezone and why this is a
useful concept, not as a 100% accurate representation of physics.
The other point I find irritating is the naming of the `Clock`
interface. While I can understand the reasoning behind it I see
irritation in the community upcoming as the `CLockInterface` now
suddenly returns 2 different things, depending on which ClockInterface
people are talking about.
While it doesn't seem to be written down as policy - but I could swear
this topic came up on Internals at least - PHP doesn't use the
`Interface` suffix to indicate interfaces in newly designed APIs.
Following the precedent established by ext/random in PHP 8.2 with
Random\Engine, the interface is the bare name and the concrete
implementations sit in a sub-namespace named after the interface.
Thus there is a clear difference in naming even for the unqualified
interface name.
Is there a way to Unify the ideas behind Time\Clock and
Psr\Clock\CLockInterface?
The proposed new date/time API is a greenfield design to fix issues with
the existing API. We deliberately don't want to “infect” the new API
with ideas from the legacy API and returning an object carrying a
timezone from a clock, as done in PSR-20, is the wrong design. `now()`
is the obvious name for the method and that's why the RFC indicates that
an adapter is required to satisfy both interfaces from the same source
of truth during the migration phase.
As right now the Time\Clock is not a direct replacement of
Psr\Clock\ClockInterface as - at the current time - there is no way to
generate a DateTimeImmutable directly from a Time\Instant.
Yesn't: You can bridge the gap by using
DateTimeImmutable::createFromTimestamp($instant->getUnixTimestamp())->setMicrosecond(intdiv($instant->getNanoseconds(),
1000)).
That said, I acknowledge that it's not particularly pretty and we
discussed adding another fromInstant() constructor and ->toInstant()
getter to DateTimeImmutable. The compatibility layer would be sitting on
the old API to keep the new API clean.
Best regards
Tim Düsterhus
