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
The world will end on December 21, 2012 anyway.
"I bless every day that I continue to live, for every day is pure profit."
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...
Don't hard code dates, calculate them. If you have reference tables for date pair values, there needs to be a process in place to update those tables. Can't think of a whole lot more that can go wrong on a year change....
Oh, dynamically calculated dates need to factor in the 12/31 to 01/01 change, formulas / functions that work the other 364 days tend to fail here in their first year in production a lot. That only applies to the actual year switch though, and when the app/report is specifically run on 01/01.
Anything else?
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.
. . .is a Western disease.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
What does this have to do with Unit Tests?
Seeing as I got an automated message castigating me for not filling out my electronic timesheet for 12/30 (a vacation day), and I heard tales of some folks getting a double paycheck and being asked to pay the extra back, I'm guessing the answer is no.
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.
Do this, and 99% of time-related bugs never occur. The problems with date-related logic almost always stem from some programmer thinking that they should carry a date around internally in a broken-out, human form - and that is always a mistake.
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'm sure it will break at any moment, since it's not supported by a big, expensive company like Apple or Adobe. Think I will see smoke first?
Great. Now I can list "follows best practices of software giants such as Adobe and Apple" on my resume!
I am itchin to fire up the old minicomputer and see what it thinks of 2013..of course i have been saying that since Y2K. Too bad it would mean turning off all the electrical stuff in my house to get enough juice to spin up the HD :O
1983 Wang computer..the login screen had calenders loaded until 2030 was always curious if it really would have been ok but noone wanted to risk it and it was retired in 1998. Can't believe it's been 14 years and i haven't even seen if it still works, altho that 1960 watts draw on the HD alone and the 5 lb transformer on the CPU box are a little intimidating. Time sucks
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.
How many people will be using a 50+ year old OS/app in 2050 when it would become a problem?
This other /. artical says it best How Can I Explain To a Coworker That He Writes Bad Code?
It's now almost 35 years ago, when I had to write date routines that spanned the year 2000 and only use 2 char year, and only use the same 5 nibbles of storage that the julain date was stored in, in the end that system could handle a ~250 year period it took about about 500 Bytes of size. Then I wrote a rouitne that in 13 nibbles handle that same time period got us down to 8ms ticks. We then used them every where in the system. It is not hard, just need to be tested.
Why are these bad coders still in the system, that can't do the simple math let alone simple testing.
Specifically temporal consistency. A guy by the name of Snodgrass wrote a book on it and I urge everyone to al least skim through it. See his website: http://www.cs.arizona.edu/~rts/
putting the 'B' in LGBTQ+
I test for all possible future dates.
http://henry.pha.jhu.edu/calendar.html
No one would be stupid enough to set the system clock to local time.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Funny, that's exactly what we said in the 60's, 70's and 80's when we used 2 digit year codes to save space.
Here is one that really bit me in the ass once. Daylight Savings Time happens on different days depending on which country you are in, and the operating system doesn't always know when this should be.
Back in 2007 I was deployed to Iraq supporting military systems. In Iraq, Daylight Savings happened on April 1st and October 1st, but Windows didn't know that. Using the Baghdad time zone Windows thought that daylight savings happened on the same days that it did in the US. So, for about a week, every computer on the domain had the wrong time. The administrators of the domain controller didn't think this was a big deal, and things will fix themselves soon, so why bother adjusting our clock? Normally that would be fine, since the military has standardized on Zulu (GMT) since forever, and all military systems were required to store and transmit dates in that format. But there was one system, which I won't name, that used local time for its database and then asked Windows to convert to Zulu time for the XML data transfer. It took several days before we found out that every date and time we were given from them was a lie. This caused us all sorts of problems and fixing all of the dates was a major pain.
After all the complaints, the meetings with developers, and so on, we naturally thought that the developers for this system had gotten their act together and fixed their problem so we wouldn't see it again. Nope. Sure enough, in October we had the exact same problem, except this time I was watching for it and modified our insert into SQL Server to adjust the time. (I'm not a fan of putting a lot of business logic in stored procedures, but it really helped that time.) I made sure that my replacement was aware of the situation before the next change in April, but apparently they finally fixed their database by then.
What I learned is that databases should always use GMT and you should never ask the system for the local time and then convert to GMT, as it may lie. Instead ask the system for the GMT time.
dayum. I haven't heard the word "framemaker" in like an aeon or two. I thought it bit the dust when Quark and InDesign took over.
Shoes for Industry. Shoes for the Dead.
don't forget mysql (regardless of platform) will also fail. I'd be even more worried about embedded systems than any silly pc or server.
and daylight savings time is the worst idea ever!
and any number of economist types have even told us that it totally fails at its advertised advantages. ;-)
But I wouldn't call it the worst idea ever. It's social and economic problems aren't in a league with such ideas as slavery, war, and religion. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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>
In late 1999, we tested a product by rolling the date forward to 2000-01-01 and it worked fine. Then we rolled the date back to the normal date, and files that got touched during the test period caused trouble, because their modification date was "IN THE FUTURE!?!?!?" as one piece of code put it. The most broken was the timestamp data for a time-based UID generator, which flat out refused to run, saying that it was in danger of generating collisions.
If that is causing your software to crash or to start have issues then STOP PROGRAMMING! Proper programming prevents those kind of issues. I'm not saying that you shouldn't test for this kind of issue but if you program properly in the first place a date overflow wont crash your software. You tend to see this kind of error with Object Oriented programmers, a good C programmer will have handled this before it happened.
I've seen a vendor issue a super-urgent patch. IIRC, it contained an update to an expiring CA certificate. They could have forseen this issue with time-shift testing of the type you did (which 'breaks' your test, but it also proves the need to install update CA certs by a future date)
My other post has an example why time-shift testing is important.
http://apple.slashdot.org/comments.pl?sid=3356429&cid=42472583
(It was the same vendor in both cases)
We have a Microsoft Sharepoint system at work where we log our project hours. Hitting Save now moves all hours to one later date, until everything is deleted at January 7th...
I built a set of DOS-based diagnostics tools for SCSI tape streamers about 20 years ago. The logging function checks for time validity and asks the user to try and find me if it is really beyond 2038. And yes, I tried testing that, except DOS didn't let me set the date beyond its valid end..
To Terminate, or not to Terminate, that's the question - SCSIROB
Ah yes... Back when 1999 turned into 2000 we did have a small Y2K problem... We used a support system written in perl where the naive programmer assumed that the year provided by the 6th field of the localtime decoder was the two last digits of the year. So to get the actual real year he prefixed the year with '19' as a string. This works fine until the year 2000 is reached. As the 6th field of localtime is the number of years since 1900, not just the last two digits, the year becomes 19100, not 2000. This makes all dates prior to 2000 (19100) very, very old and any and all posts will thus get purged in the general cleanup... Thankfully we had a working backup...
The code was full of homemade conversions between dates, complete with other whopping errors.
Smarter systems use only seconds internally and only convert to dates for display purposes or to find "stuff from this month" or similar.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Surely you jest. Well at any rate I'm sure they'll fix it with an 857MB patch to Adobe reader.
And now try the same using the datetime datatype.
Incidently, the timestamp is (in the mysql manual) described with a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC. So it's not a bug, it's a feature.
iOS has another problem because it does use GSM to get time. If you live on the edge of a time zone, the time is affected depending on which cell tower is in use and what time zone it is in. A friend of mine uses an iPad in a city on the state border. His calendar app works fine at one end of the building. When he goes to the other end of his building, a cell tower in a different time zone is in use and the time is off by an hour when he creates a new appointment.
Most date bugs I've seen (and coded earlier in my career) related to "close enough" approximations of the right logic, that turned out not to be close enough for one reason or another. Some of this related to insufficient information... one clock assumes what the other is doing but can't get info from that clock.
But a larger fraction was just that doing things with stupid hacks way was vastly quicker because with a different APIs every time, and always verbose and clumsy, it's not tempting to do a deep dive every time and really learn what the hell is going on in there.
We've seen with another ~practically~ fundamental datatype, strings, that dsls make this much less of a PITA. So why 40 years later do we not have something similar for timestamps and intervals at least for the damn gregorian calendar? (would take a lot more thought to generalize over others, maybe worth the effort, maybe not). I ask this seriously because I'm kind of tempted to tilt at this windmill, do a spec and first implementation for Java, at minimum, maybe also JavaScript and an sql dialect or two.
I actually knew of an old mainframe system that had to be switched off for an hour when the clocks went back so that it didn't get confused and try to log the same time twice.
Sigs are so 1990s. No way would I be seen dead with one.
The Apple one is really odd - because if you read Apple's response, it makes no sense. It automatically fixes itself on January 7? WTF? Date/time bugs don't usually have self-expiry dates (though Apple's response is adequate since the bug will auto-fix itself before Apple could fix and test the update). And especially since there's nothing seemingly *special* about January 7...
Ars has a nice write up about it - http://arstechnica.com/apple/2013/01/ask-ars-why-will-apples-do-not-disturb-bug-fix-itself-next-week/
TL;DR version: The DND bug is because well, to the DNS part of IOS the year is 2012. In fact, it's technically week 53 because of the way Apple chose to code DND.
It's a mismatch between the calendar date and the ISO Week date (at least, the consensus seems to be this since the effect is reproducable and a bit of silliness in NextStep APIs make it a REALLY easy bug).
There's even code that repros the bug.
It happens. For example, in the late eighties, when I was still on a mainframe, halfway through my stint at at Fortune 500 company (referred to, ever since, as the Scummy Mortgage Co, SMC, actual name available upon request, and for many, many, many reasons), they fired (not laid off) the other online programmer, who'd been there 10 years. A few months later, I found his "algorithm" for leap year in most of the online systems: if it was 76 or 80 or 84 or 88 or 92, it was a leap year.
I kid you not.
I went to my boss, the VP of DP, and told him about it, and he said, is it broke? I told him it would be broken in a couple of years, and he told me, "if it ain't broke, don't fix it". But, but, I said, and he replied, "we'll fix it whern it breaks".
And this was in a *mortgage* co - y'know, people who have to calculate 30 mortgages?
mark, shaking head
... metric time -- bring on kilodays, nanodays, all of it. I can't wait another microday for this.
yes, that is 64 bit, the issue is in how mysql stores the data not OS
it's a poor design, it will cause problems for applications such as mortgage or actuarial tables
I found an "amusing" bug in a software deployment system recently that will break horribly on Jan 1, 2022. (Much sooner than the usually announced doom-dates of 2038 and such).
It's a fairly simple cock-up, so I wouldn't be surprised to find it elsewhere.
Step 1: Make decisions based on a datestamp.
Step 2: Define that datestamp as "YYMMddHHmm".
Step 3: Somewhere along the line, shove that string into a 32bit signed integer.
The maximum value we can store is thus "2147483647", so the "2201010000" of Jan 1, 2022 will overflow to a negative value. Hooray!
Completely stupid. Completely avoidable. Using the standard "milliseconds since the epoch" we're still only at "181825596", and would have made it all the way into 2038 before running into a similar failure. My only solace is that we'll have abandoned this particular software by then. YOU may not be so lucky...
As long as your system uses milliseconds since the epoch internally, daylight savings (and leap years, and leap seconds) are all simple problems of translation for human-readable display and will not effect functionality.
It's the difference between what we "call" a particular point in time and how much time has physically elapsed.
That said, I'm completely not sure how to properly deal with computers in highly accelerated reference frames who will have experienced a different quantity of elapsed time than their stationary compatriots...