Technically, the Zune bug didn't kill the device. The bug sent it into an infinite boot loop until the following day when the leap year calculation could return.
But yes, the difficulty in verifying a correct implementation of date and time calculation calls out for a standard test apparatus to "prove" correct results for a defined scope.
I once stupidly implemented a "date math" feature, and after introducing numerous bugs in production opted to use https://svn.python.org/projects/sandbox/trunk/datetime/test_... as my ref. test (which exposed numerous other bugs). Likely not full coverage of all date-time related bizarrities, yet a useful resource.
That and/or "rip out this idiot date math library written by your predecessor and try to use an industry standard library instead". Especially the karma of first one then the other.
About the only way to keep your sanity is to treat dates in only one of two ways, depending on the context:
1. As a string you don't touch
2. Convert to seconds_since_the_epoch immediately. Convert back only when necessary (when printing to the screen or sending to a SQL query for example).
This calc problem is somewhat unique because months and years aren't fixed length and it's probably bad if your program says Feb 1 to March 1 is less than a month, or Jan 1 2000 to Jan 1 2001 is a year and a day. Or if Jan 1 2001 to Jan 1 2002 is a year and a quarter of a day. And then you have to account for those occasional years that are divisible by 4 but are not a leap year. And then you have to account for when someone asks for the difference between September 1 1752 and September 20 1752. Pretty soon you're remembering why rules 1 and 2 exist. It should be noted that calc.exe gets this wrong in many ways.
But yes, the difficulty in verifying a correct implementation of date and time calculation calls out for a standard test apparatus to "prove" correct results for a defined scope.