Yep, seems to be the same issue.

see #31374 for an attempt to fix this

Closing as fixed by #31374.

That PR wasn't merged. Thus let's reopen here.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Still broken I guess.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Just a quick reminder to make a comment on this. If I don't hear anything I'll close this.

As @xabbuh already indicated with the label: I still think properly handling all dates in these types is important.

Who wants to investigate this issue and maybe work on a fix?

I have started to investigate this problem and so far it seems to work correctly that the date before 1582-10-15 is not a valid date according to the Gregorian calendar. If someone enters a date that is on or before 1582-10-14, then there the date entered is intended to be a Julian calendar string date (<1582-10-14 is an invalid date in Gregorian cal.). This date needs to be converted to a Gregorian date, since \DateTime handles well only the Gregorian calendar.

When the time zone enters the picture php starts to do very strange things. Further research is needed to find out how this part of the PHP works.

If I don't allow pre-Gregorian dates to be formatted by IntlDateFormatter in the DateTimeToLocalizedStringTransformer::transform method, then PR #31374 starts working correctly even if the timezone is not UTC. The main reason for this, I think, is that IntlCalendar cannot be Gregorian, so I have to define my own. I can't yet see if IntlCalendar can describe the Julian calendar behaviour, or if in this case I have to skip the intl formatter altogether.

        if ($timestamp >= -12219292800) {
            $value = $this->getIntlDateFormatter()->format($timestamp);
        } else {
            $value = $dateTime->format('Y-m-d');
        }