PHP 8.6 gets Time\Duration, the first piece of a new date and time API. This RFC, from Tim Düsterhus and Derick Rethans, proposes the next piece: Time\Instant, a single point in time, plus a Time\Clock interface for asking what time it is now.

What it adds

An Instant is a moment on the timeline with nanosecond precision and no timezone. Combined with Duration, it covers "when did this happen" and "how long ago was that":

use Time\Clock\SystemClock;
use Time\Instant;

$now = SystemClock::get()->now();
$moonLanding = Instant::fromIso8601DateTimeString('1969-07-20T20:17:40Z');

echo $moonLanding->until($now)->seconds; // seconds since the moon landing

There is one system clock, so you fetch it with SystemClock::get() instead of new. You can create instants from Unix timestamps (seconds or milliseconds) or ISO-8601 strings, and turn them back with toUnixTimestamp(). If you already have a DateTime or DateTimeImmutable, the new toInstant() method on DateTimeInterface gives you the same moment. The timezone is dropped and the microseconds are kept. You can move instants with add() and sub(), get the gap between two with until(), and compare them directly with <, > and <=>.

Why not an int or DateTimeImmutable?

An int from time() drops everything below a second, and nothing in the type says whether it holds seconds or milliseconds. DateTimeImmutable has the opposite problem: it carries a timezone and a full calendar, even when all you mean is "this moment". Instant is just the moment.

A clock you can swap out in tests

Code that calls time() or new DateTimeImmutable() is hard to test. The RFC adds a Time\Clock interface with one method, now(), so you can inject a clock and replace it with a fake:

final class FrozenClock implements Time\Clock
{
    public function __construct(private Time\Instant $now) {}

    public function now(): Time\Instant
    {
        return $this->now;
    }
}

For now PHP ships only SystemClock. The RFC lists more clocks, including ones for testing, as possible future additions.

What it deliberately leaves out

  • Formatting and timezones. You can't print an Instant as "Monday at 3pm", because that needs a timezone. A class that pairs an instant with a timezone is planned as a later step.
  • Leap seconds. They are ignored, as in almost every language.
  • Measuring elapsed time. The system clock can jump, even backwards, so two readings can give a negative duration. A separate monotonic clock is future work.

What it means for your code

The RFC lists no breaking changes. Its three new names live in the Time\ namespace that was reserved for this API in 8.6. DateTimeInterface gains a toInstant() method, so a class extending DateTime or DateTimeImmutable that already declares its own toInstant() could conflict. Time\Clock covers the same ground as PSR-20's ClockInterface, but returns an Instant rather than a DateTimeImmutable, so expect libraries to offer adapters between the two.

Where it stands

Tim Düsterhus opened the internals discussion on September 21, 2026. The RFC was updated on September 23 to say serialized instants will be portable. A September 29 revision added toInstant() and changed how the ISO-8601 output shows fractions of a second. On October 6 and 7 the authors moved toInstant() onto DateTimeInterface, renamed the getUnixTimestamp() methods to toUnixTimestamp(), and made SystemClock a single shared instance. On October 29 they clarified that ISO-8601 strings need a zone offset such as Z or +02:00, since the parser won't fall back to PHP's default timezone. Three questions are still open: whether to add more exception types, exactly what range of dates an Instant supports, and how the ISO-8601 parser handles input it can't store exactly. On November 2 the authors marked SystemClock as not serializable, since there is only one.

It targets PHP 8.7, and no implementation is linked yet. No vote has been scheduled. A vote would need a two-thirds majority.