Hi
Am 2026-06-19 19:12, schrieb Marc B.:
Omg, I wrote in a wrong way - sorry.
I mean the RFC just mentions "The Time\Duration class will also
implement internal “comparison handlers”, which means that direct
comparisons with operators such as < will work".
So there are no other operators defined but there are methods defined
for it. I would expect these defined as operators as well.
See my reply to Larry.
Actually, for the division, there are two use cases but the method
supports only one.
6s / 2 = 3s
6s / 2s = 3
This is a good point, though. While we're probably not going to
implement Duration/Duration from the start, we should account for that
in the naming of the Duration/int method. Do you have any suggestions?
Rust’s std::time::Duration calls these `div_duration_<variant>`. Java
doesn't have it, but could technically just use method overloading. And
in Golang it will just implicitly work, because `time.Duration` there is
just a 64-bit integer without any “unit”.
To support Duration/Duration->int it would also be necessary to restrict
the entire range to a signed 64-bit integer of nanoseconds, because
overwise `Duration/Duration->int` might overflow on 64-bit systems. This
is already something I considered doing based on off-list feedback I've
received (and lifting this restrictions later is always possible, so
better play safe). I'll discuss this with Derick. We'll also need to
define the overflow behavior in general (e.g.
`Duration::fromHours(PHP_INT_MAX)->multiplyBy(PHP_INT_MAX)`).
5. Did you thought of supporting float on the initializer methods?
Floats introduce all the complexity and lack of precision of, well,
floats. Best to avoid them.
If you have a float at hand you already have the lack of precision.
Forcing the user to cast to int before does not make anything better.
It's even another source of complexity the user have to deal with. If
this gets handled on the initializer it will reduce the complexity for
the user.
See my reply to Larry and Seifeddine.
Best regards
Tim Düsterhus
