This is indeed an intended big fix. As this change doesn't violate LSP (the inherited child class still follows the is_a relationship with DateTime), how does it cause a problem in your situation?

As part of the Chronos (date/time library), we have a Date type that wraps DateTime and handles ensuring date-only values.

There is logic that checks if creating an instance from a Date object or not to determine what to fix up. With this change, the unfixed instance is simply cloned.

Since DateTime::createFromFormat('Y-m-d') takes the current time all this logic was added to ensure construction was valid.

To be clear, this behavior seems like the correct behavior and should have been the original behavior, but since this will take some re-design to work with PHP 7 and 8, it's worth checking this won't revert back.

One issue we will have is knowing when this object was created.

https://3v4l.org/k5gDZ

Is there no indication that the derived class was instantiated from createFromFormat()?

If the subclass is going to be returned by DateTime::createFromFormat() shouldn't its constructor also be used?

https://3v4l.org/LqeX2

Shows that while the subclass is returned, its constructor hasn't been returned which is something I would expect.

Looking into this further, I see how calling the constructor would be tricky.

The time would need to be calculated from the createFromFormat parameters and then converted to a standard/ISO format to pass to the constructor to actually instantiate the object.

However, it's really an awkward scenario to deal with since there's no initialization of properties through the derived constructor.

I don't there should be a reason why a factory creation method should call a constructor? Normal PHP also does not do this: https://3v4l.org/ekOtT

I'm sorry, I don't follow your example. It isn't a factory. It's just a static function that echos.

Can you explain the logic behind a factory not constructing?

Yeah, the current behavior here is not great. I think it should either continue returning self, or call the constructor for extended classes.

A workaround would be to do something like

class MyDateTime {
    public static function createFromFormat(...$args) {
        $date = parent::createFromFormat(...$args);
        // Do the rest of your initialization here
        return $date;
    }
}

Our work-around is constructing the object twice. We take the result of parent::createFromFormat() and format() the full string then new static() to ensure the constructor is called which is necessary as it clamps values.

I tried implementing the logic I mentioned of using timelib to calculate the time formatting a similar string to then construct the instance. However, as my first attempt working in php, figuring out how to execute the derived constructor and such from the date code proved impossible.

I am inclined not to change this back now again in PHP 8.2, as it's been two years and changing it back will just end up causing more work.