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 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.
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>