Adobe and Apple Didn't Unit Test For "Forward Date" Bugs. Do You? 169
llamafirst writes "As the year flipped to 2013, we learned that Adobe and Apple don't test for "forward date" bugs. Adobe prevented any copy of FrameMaker 10 from launching and Apple broke Do Not Disturb for the first week of 2013. Surely some more critical and safety systems also have lurking issues. Got tips for catching time/date bugs 'from the mysterious future?' (Also, obligatory link to Falsehoods programmers believe about time.)"
OP change the title (Score:2, Insightful)
Why add "Unit Test?" just say "Test" unless you really mean a unit test.
Very simple...but misses many common needs (Score:4, Insightful)
Frequently, calculations require both points in times and intervals of time; the former can consistently be represented as seconds since epoch, the latter doesn't really have a usable equivalent (you could use just seconds, but then things don't work as expected, since often its actually important to the user that the interval be an exact number of days, weeks, months or years, which may not be reducible to a consistent number of seconds, but instead that will depend on how the point in time the offset is being calculated against is represented in Year/month/day/hour/minute/second form, because leap seconds, leap years, and different lengths of months all make interval calculations tricky.)
You can't restrict conversion of seconds-since-epoch to calendar format to display-purposes-only if you are going to do anything useful with dates.
Re:Simple... (Score:2, Insightful)
I think all dates and times should be stored in UTC (not GMT). Storing them in anything that is affected by time zones and DST is just asking for trouble. DST and Time Zone are presentation problems ... not storage problems.
Re:Automated testing (Score:2, Insightful)