Why not use DateTime::__set_state(['date' => ...])?

Though I do think that we also need to migrate away from __wakeup to __unserialize to avoid the reliance on temporary dynamic properties. And unserialization is clearly missing some checks in this area.

I could work with that I think, but then I figured this doesn't work with child classes of eg DateTime:

class Foo extends DateTime
{
}

echo get_class(Foo::__set_state([
    'date' => '1970-01-01 00:00:00.000000',
    'timezone_type' => 1,
    'timezone' => '+00:00',
]));

Displays DateTime.

I cannot figure out a way to make this lib support PHP 8.2 while not triggering a warning.

you can set dummy error handler and remove it after the object is hydrated

you can set dummy error handler and remove it after the object is hydrated

Well, that's not a proper solution. It will break on PHP 9 if we don't do anything else.

Something that works for DateTime* even when dealing with child classes is to call their constructor via reflection:

class Foo extends DateTime
{
}

$foo = new Foo();

(new ReflectionMethod('DateTime', '__construct'))->invoke($foo, ...)

But for DateInterval and DatePeriod, this doesn't work because their state depends on the way they've been created (using DateTime::diff() or not, etc.)

Another solution would be to implement __serialize/__unserialize in PHP 8.2. We'd still have to try to ensure that pre8.2 payloads are still serializable.

Why wouldn't it make sense to declare these properties (without initializing them)? So that writing to them is not a dynamic property access.

I see no concrete disadvantages to that.

Another solution would be to implement __serialize/__unserialize in PHP 8.2. We'd still have to try to ensure that pre8.2 payloads are still serializable.

That would be my preference. Pre-8.2 payloads should still unserialize fine, because the __wakeup and __unserialize formats are compatible.

Some historical perspective:

• These properties were never meant to be public — as setting these would imply that they would modify the underlying data (they don't).
• They were added to be displayed for debugging and tests (through var_dump() and friends).
• Somebody later added serialisation support, and __wakeup() etc.
• Using __wakeup() to magically make the DateTime properties do something is IMO also a hack.

None of the DateTime* classes should have publicly writable properties, and the right way to hydrate these objects is/was by using __set_state.

I do find it odd that Foo::__set_state() wouldn't return a Foo class though, and I think I consider that a bug. There is however no other built-in class that implements __set_state() in the standard distribution.

FWIW, I've started adding the __serialize/__unserialize methods for the Date classes.

PR 1: #8422

The DateTime/DateTimeImmutable/DateTimeZone part is now merged.

PR 2: #8459 (for DateInterval)

PR 3: #8464 (for DatePeriod)

All the classes are now covered, and their PRs merged, so closing this ticket.