Slashdot Mirror
Adobe and Apple Didn't Unit Test For "Forward Date" Bugs. Do You?
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.)"
2012 cost us a decent chunk of change because for the third product line in a row, we screwed up seconds since epoch calculations... Every single customer was out of commission until we released a patch!
I am d3matt
They left December out of Android Jelly Bean's date picker.
Why add "Unit Test?" just say "Test" unless you really mean a unit test.
Why does software functionality depend on the date? Calculation issues maybe... but failure to lauch? WTF? I'm most curious to learn how this even happens.
...with forward dates braking my tests.
I've had mock SSL certs and HTTP cookie jars that both expired and made it seem like the system was failing all over the place during unit/integration/general testing.
So just watch out in general because this can swing either way...
I for one am stockpiling canned meat in my bomb shelter for 2038. By the time 2038 comes, software will be so virtualized and there will be so many layers between operational computer software and what's under the hood that it will take at least a decade to fix this problem in our future society.
Well, there was no point in forward testing after Dec 21, 2012, you see.
I've fallen off your lawn, and I can't get up.
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.
My shop has over 800 automated test scripts, all of which have been running on machines that think it's 2013-2014 for over a year, and will be bumped up to 2014-2015 by the end of the month.
I could supply link, or better yet let's make the proof this thread. See how timestamp beyond 2038-01-19 03:14:07 gets foobared.
rubycodez@hyperion:~$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 40
Server version: 5.5.28-0ubuntu0.12.04.3 (Ubuntu)
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> create database timedb;
Query OK, 1 row affected (0.00 sec)
mysql> use timedb;
Database changed
mysql> create table tvalue(t timestamp);
Query OK, 0 rows affected (0.00 sec)
mysql> insert into tvalue values ('2012-12-21');
Query OK, 1 row affected (0.00 sec)
mysql> insert into tvalue values ('2038-01-30');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> select * from tvalue;
| 2012-12-21 00:00:00 |
| 0000-00-00 00:00:00 |
2 rows in set (0.00 sec)
mysql>
Bull, I find bugs all the time *because* dd/mm/yyyy in applications is often stored/operated on with millisecond/second precision.
Let's see:
a) the case of the missing midnight: some date or another in the 1920's IIRC that doesn't have a 00:00:00 hour but that day starts at 02:00:00 hour (so, two missing hours). Unable to create or store that date with the time set at midnight.
b) range 01/01/2012 - 10/12/2012 entered by the user, inclusive. On 10/12/2012 00:00:01 the system determines the current date is no longer in the range. Bug, certainly not what the user intended.
c) amount of days between 1/1/2012 CET and 1/6/2012 CEST. A naive way to calculate this is is to subtract the two dates (with millisec precision) and divide by 24 hours. That will give the wrong answer though.
Anyway, I've come to believe that in an application you store/use the date the user typed in, not a derivative with millisecond precision.
And, also agree with DragonWriter above.