On Tue, Sep 22, 2026 at 10:23 AM Tim Düsterhus <[email protected]> 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 Hi Tim, Broadly in favor. The timezone-less design and keeping the compat layer on the old API are the right calls. Three things I'd like pinned down before a vote: 1. toIso8601DateTimeString() output width. Omitting the fraction only when it is zero makes the output format depend on the value. A consumer that can't parse fractions passes tests with whole-second fixtures, then fails on almost every SystemClock value in production, so the interop benefit doesn't hold. It also breaks string ordering: "2026-09-29T16:42:45Z" sorts after "2026-09-29T16:42:45.500000000Z", and people do store these in VARCHAR columns and ORDER BY them. Always emitting 9 digits gives fixed width, chronological string order for years 0000 to 9999, and the explicit precision you were after. 2. The accepted grammar of fromIso8601DateTimeString(). "May not support all legal formats, extendable by a PR" means the accepted set gets decided in code review rather than by the vote. I'd like the RFC to guarantee RFC 3339 date-time (plus the expanded years the getter emits) and state the outcome for: more than 9 fractional digits, comma decimal sign, lowercase t/z, space separator, -00:00, 24:00:00 and 23:59:60. On the last one, java.time parses 23:59:60 as 23:59:59 rather than rejecting it, and RFC 3339 explicitly permits :60. Rejecting is defensible, but it should be written down. 3. json_encode(). With no public properties, json_encode($instant) yields {}. Duration and DateTimeImmutable both encode to something meaningful today, so a silent {} is a trap for any API response carrying a timestamp. Either implement JsonSerializable returning the ISO-8601 string, or state that {} is intentional. On the exceptions open issue: splitting TimeException into subclasses later is BC-safe, since catch (TimeException) keeps working, so I don't think it needs to block this RFC. Ilia Alshanetsky Technologist, CTO, Entrepreneur E: [email protected] T: @iliaa B: http://ilia.ws
