A glitch in February of the year 0

The problem arose when a team member tested timestamps in the distant past and found that some were not handled correctly, specifically with the timestamp 0000-02-03 04:00 in the Europe/Oslo timezone. The issue was found to be related to the conversion of Unix timestamps to DateTimeImmutable objects in PHP, where the last method of conversion - using `new \DateTimeImmutable('@-62164356180')` - gave an incorrect result off by one day for February of the year 0. This method was being used in the team's code, which led to the error. The root cause was identified as a bug in the timelib library, which provides date/time functionality used internally by PHP's DateTimeImmutable class.

The year 0 is a special case as it is a century leap year in the proleptic Gregorian calendar, which is the calendar used by the system. However, other century leap years like 2000 were not affected, indicating that the issue was more nuanced. The team ultimately fixed the issue by switching to a different method of conversion, specifically using `\DateTimeImmutable::createFromFormat('U', '-62164356180')` or `(new \DateTimeImmutable('@0'))->setTimestamp(-62164356180)`.

The bug fix also involved opening a pull request to correct the issue in the timelib library, which will hopefully be resolved in upcoming releases of timelib and PHP. This incident highlights the complexities and potential pitfalls of handling date and time calculations, especially when dealing with edge cases like the year 0.