Hi
On 2026-10-06 18:16, Larry Garfield wrote:
7. get vs to
I agree with this. $foo->toBar() is a very common "type conversion"
pattern, and it makes sense to use here as well.
Already adjusted a while ago.
8. getUnixTimestamp() / getUnixTimestampMilliseconds()
I would agree here as well.
See the reply I just sent to Marc.
13. A dedicated parser/formatter instead
I'd prefer parsing and formatting to live in a dedicated
parser/formatter
API (future scope) rather than on Instant, where it would sit next to
the
other ISO-8601 profiles and custom patterns. If the pair stays on
Instant,
the name should say what it really is (a fixed RFC 3339-like profile),
and
the grammar should be part of what we vote on.
I understand the tidiness/purity argument here, and I am generally
sympathetic to it. However, that always needs to be balanced against
usability. Any incoming date/time information to the PHP process is
likely to be either an ISO-8601 string or a unix timestamp int. If we
want people to convert those into Instants for doing manipulation and
comparison on (which I presume is the case), then that needs to be
ergonomically easy to do. Having to go through multiple
parser/converter objects (which some purist is likely to insist be
injected from a container rather than instantiated directly; I have
been known to be that purist) to get there is not ergonomic. So if
that logic is split off, we would need to be very careful to ensure the
result is ergonomically simple and readily copy-pasteable.
Yes, I've expanded a little more in my own words in the reply I just
sent to Marc.
Regarding the “purist note”: Injecting a formatter (into your template
engine) actually is reasonable. The correct choice there would likely be
one backed by ext/intl.
And of course, as I had noted in
https://news-web.php.net/php.internals/132608 and the reply to Marc,
arbitrary formatting is only well-defined for a `ZonedDateTime` (or
`PlainDateTime` - naming tbd - when the timezone is implied). For
`Instant` we can just use anything that unambiguously represents a point
in time, which basically boils down to ISO-8601 date time with zone
offset. Users are able to build their own parsers if they have a
requirement for special formats. Or parse into `ZonedDateTime` and
extract the instant via `ZonedDateTime::$instant` (or whatever it may be
called).
14. until() vs Duration::between()
Was Duration::between(Instant $a, Instant $b) considered? Calculating
a
duration feels like Duration's responsibility to me.
This also seems reasonable, as a named constructor of Duration.
See the reply I just sent to Marc.
Best regards
Tim Düsterhus
