Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Programming Software Apple

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.)"
This discussion has been archived. No new comments can be posted.

Adobe and Apple Didn't Unit Test For "Forward Date" Bugs. Do You?

Comments Filter:
  • by Anonymous Coward on Thursday January 03, 2013 @06:44PM (#42468419)

    Why add "Unit Test?" just say "Test" unless you really mean a unit test.

  • by DragonWriter ( 970822 ) on Thursday January 03, 2013 @07:13PM (#42468765)

    Points in time are *always* represented internally as seconds-since-epoch (or milliseconds, or whatever unit makes sense for your app). Calculations are always done on values which are seconds-since-epoch. The *only* time that a date is *ever* converted to a year/month/day hour:min:sec representation is strictly for display purposes.

    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)

    by Nerdfest ( 867930 ) on Thursday January 03, 2013 @08:00PM (#42469325)

    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.

  • by Anonymous Coward on Friday January 04, 2013 @04:37AM (#42473069)
    Why is he full of shit? Any professional business that produces software has automated scripts doing such testing. We do full regression tests on a weekly basis and nightly break tests including future dates. We run thousands of scripts. If you think that is full of shit you need to stay the fuck away from software development.

Logic is the chastity belt of the mind!