Some of you might recall how all Zune devices died on 12/31/08.
Windows_Globalization_Calendar_AddMonths_System_Int32 was the root of it all, apparently.
(For further reading on the Zune outage: https://techcrunch.com/2008/12/31/zune-bug-explained-in-deta...)
Many interesting debugging stories are collected in this GitHub repository [3].
[1] https://github.com/angular/angular.js/issues/5017
I've found countless ones of these. Some of them in date/time/timezone handling libraries.. :/
https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
Absolutely loved reading through the bug! haha
What's the underlying issue, really? Is it that detecting file types by checking for magic strings is always a bad idea? Or is it something more basic about the architecture here, more like the leaky abstractions problem?
So, I would actually disagree with the author that it is strictly a bug in the ‘file’ utility, as there is simply no completely reliable way to determine intended file type by just looking at the content[1]. You have to transmit that information out of band, and this is why we have MIME types sent through Content-type: headers in HTTP or email headers. File extensions are another method (though also ambiguous: .TXT and .EXE are almost certain, but a .DB or .BAK can be one of many things).
CUPS is probably applying this heuristic for convenience (“send anything to your printer and it just prints!”), at the cost of correctness.
[1] A simple proof for that is the existence of “polyglots”, which in this context are source code that happens to be a valid program in two or even more different programming languages (often doing the same or similar things for sport). Were CUPS to differentiate printing based on the programming language, e.g. by applying different syntax highlighting, it would not know what language to choose, and without out of band information there hardly even is a “right” answer. In practice though you can detect a file type more reliably than ‘file’, but at much more complexity than “let’s check some magic numbers in some offsets to give the user an idea of what this might be”, and it still wouldn’t be perfect.
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 believe this to be one of those rites of passage for any programmer.
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.
oh my sweet summer child