Not today but several years ago while lending a hand on a project that was wildly overdue and the guys needed all the help they could get. Disclosure: it was not in software that was in production yet(otherwise you would have likely heard and been affected by it by now I suspect). The software's purpose was dealing with commercial airlines - routes, connections and all that. The travelling salesman problem basically. The software was meant to replace an antique system which no one knew how to maintain since in 2020 it was still running on mainframes and written in fortran. There were specifications on how the system worked but there was no one who could even read the code. Anyhow, the way dates were stored, read and calculated was absolutely insane. I can't recall what the exact deal was, but each date was represented with either 4 or 5 bytes with some really awkward algorithm to make it into something meaningful. With a bunch of additional patches surrounding Y2K.
Unfortunately it was a lot more subtle than getting March 1-st instead of Feb 29-th. Each date was calculated with a dynamic offset depending on the month and year. So during leap years, everything was fine until the 14-th of May at 01:00 UTC. The second the clock hit, 14-th of May at 01:01, all hell broke loose incrementally as time want on until the end of each year. The weird string representation for Nov 1-st was being calculated as January 3-rd for instance. But as soon as the clock hit January 1-st, everything went back to normal. It took 6 people 2 days to figure it out. As you might expect, this was not mentioned anywhere in the documentation.
I'm not sure what has happened ever since, but if the system made it into production and you didn't get stuck in an airport... You're welcome lol