June 28, 2026
Zero hour, maximum drama
A glitch in February of the year 0
A tiny date bug turned into a full-blown year-zero identity crisis
TLDR: A real PHP date bug was shifting some ancient dates in February of year 0 by one day, and developers found a workaround plus a broader fix. But the community fixated on the bigger chaos: whether year 0 should even exist, turning a bug report into a calendar flame war.
What started as a weird little bug report about an ancient timestamp quickly turned into the internet arguing with the calendar itself. The company found that one specific way of reading very old dates in PHP, a popular programming language, was pushing some dates in February of year 0 back by a whole day. The practical fix was simple: use a different method. But the comments? Oh, the comments went straight past software and into historical theology, calendar law, and zero-based chaos.
The loudest reaction was basically: “Excuse me, year 0 does not exist.” One commenter declared that the real glitch was believing in year 0 in the first place, dragging in the fact that the old Christian calendar jumps from 1 BC to 1 AD. Another came in with peak forum energy, joking that anyone who disagrees should take it up with the Pope. That turned a niche date bug into a surprisingly spicy fight over whether computers, historians, and religious tradition are even talking about the same timeline.
And that’s what made this so deliciously nerdy: the bug was real, the fix was real, but the crowd became obsessed with the deeper drama of who gets to define time. Instead of just saying “thanks for the patch,” people treated the comment section like a courtroom for the very existence of zero. It’s part bug hunt, part history lesson, and part accidental comedy sketch about how even a broken February can start a culture war.
Key Points
- •The bug was discovered while adding support for ancient timestamps and could be reproduced with `0000-02-03 04:00 Europe/Oslo`.
- •The issue affected all time zones but only dates in February of year 0 and the last few days of January.
- •The problem was traced to a specific PHP `DateTimeImmutable` constructor form using `new \DateTimeImmutable('@timestamp')`, which returned dates off by one day for this range.
- •Alternative PHP conversion methods using `createFromFormat('U', ...)` or `setTimestamp(...)` produced correct results and were adopted as a workaround.
- •The underlying cause was identified in `timelib`, where one Unix-timestamp-to-date conversion path used an incorrect range-check date in January of year 0, and a pull request was opened to fix it.