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.
The "Broken by design" paradigma is already patented by Microsoft. Hope they have some spare billons for the incoming lawsuit.
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.
Adobe's case? No, because I don't implement fucking DRM. Also, ha ha, pirates again score the better product versus honest customers.
Apple's case? Absolutely, because behavior is supposed to change based on calendar events. We have some unit tests for that, right?
...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...
Normally, the obligatory "It's a bug not a feature" comment would be sarcasm.
... there will be plenty of people who think it's genuine.
As with most things apple, though
We test our edge and special cases pretty thoroughly, "beginning" and "end" of time, every DST spring/fall, and leap years/seconds.
Still have bugs though.
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.
we need an accurate method of identifying and solving these future bugs because they are playing havoc with my Tardis!
I got to the chocolate box before you, that's why the hard ones have teeth marks.
Our software only needs time periods less than approx .2 seconds. And we have everything in Zulu and represented as tai64n. Converting to/from human readable time is not our problem
and daylight savings time is the worst idea ever!
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 biggest fear is an expiring certificate ending civilization.
Outside of testing around DST boundaries I don't test for the future specifically. Past is prologue.
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?
Since I'm working on code that does not really care what day it is, this is a REALLY silly problem to worry about.
That is, if it is important to you, it means you are writing code which is GUARANTEED to fail to work sometime, based upon WHEN.
One of the features I had the (mis)fortune to develop dealt with future offsets, DST, and different timezones. I knew to test it. How does anyone not think to test DST and year-end rollover for a TIME app!?
Great. Now I can list "follows best practices of software giants such as Adobe and Apple" on my resume!
Commercial software is rife with forward date bugs. To deal with the Y2K problem many companies modified code to assume that any two digit year less than or equal to 50 was 1900s and any two digit year greater than 50 was 2000s. How many of those companies took the time and spent the money to go back and update their software to four digit years?
Why would a forward year matter in the first place? What kind of sloppy code is being written that can't cope with a simple change in the year?
I shudder to think...
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.
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.
Don't test. Inspect.
If you can't inspect, how do you plan to exit test?
http://www.mfagan.com/pdfs/ibmfagan.pdf
There's a "date problem" for you, lol... -> http://en.wikipedia.org/wiki/Year_2038_problem
* :)
APK
P.S.=> Let the 'flames' commence - Yes, there are "fixes" but do ALL 32-bit UNIX's employ them? I doubt it...
... apk
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+
Forgot to preview
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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.
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.
My personal favorite is that a time only happens once.
Alas it isn't true when the time goes back an hour for dst and you are foolish enough to store the time in local timezone.
It's part of WHY I posted it (brake systems especially) -> http://en.wikipedia.org/wiki/Year_2038_problem
* VERY GOOD of you to note what you did though...
(Thanks much, on the tip on mySQL - as I had NO IDEA on that much!)
APK
P.S.=> Lastly - Do you have a link to that issue on mySQL? I'd appreciate it, & "TIA" (thanks-in-advance)...
... apk
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.
As good as required I suppose - good catch, & I *wish* I knew that back in a database class I took years ago that was implemented using mySQL in fact...
Would've knocked the prof. for a loop...
* Thank-You... your select query result does the rest!
(Would that also hold true on the 64-bit version of mySQL as well, since it IS 64-bit? Just curious...)
APK
P.S.=> I am assuming that is truthful here, & though I have the 64-bit version of mySQL downloaded here to test? I just have NO inclination (or energy tonite to be honest) to load it & test...
... apk
Per my subject-line above - PERTINENT QUOTE/EXCERPT:
"MySQL database's inbuilt functions like UNIX_TIMESTAMP() will return 0 after 03:14:07 UTC on 19 January 2038.[6] The limit reached will vary in time, based on the time zones as in the following table:" FROM -> http://en.wikipedia.org/wiki/Year_2038_problem
(Yup - I am TIRED tonite boy... lol!)
APK
P.S.=> Still, ) really am interested if this would be a problem on 64-bit versions of mySQL too... shouldn't be, but they don't really specify in the link above either, so... hence, my question to you in my other reply! You may already know the answer since you are using it regularly it appears, & are maintaining 40 connections to it I see as well...
... apk
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...
No.
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
Surely you jest. Well at any rate I'm sure they'll fix it with an 857MB patch to Adobe reader.
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.
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.
This is to be expected of these two companies in particular, they notoriously use outdated tech on their modern applications, change features without warning and are generally only interested in making money, not providing a quality product. Not saying they've always been this short-sited but the bigger they get the worse they get. You think with increased access to resources you wouldn't have to lie and brainwash the public into thinking that they have great products.
Out of the box it's got that wow quality everyone wants, and then you use it. Most Apple users these days are so guilt-ridden into not complaining that I fear a whole generation has been negatively affected in how to provide quality feedback which means much extra time dealing with crappier and crappier products. The worse part, other companies try to emulate this.
Adobe and Apple both may have brands that will last for years but for the most part - these companies that I used to love have lost it a long time ago. Adobe being the worse out of the two if you can believe that. They are just hateful at this point against their own supporters.
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
1) Who cares if the devs didn't unit test. That just means they missed a step. The QA team should have caught it with manual testing/automated testing/magic.
2) To the people who can't figure out how dates can bite you. Consider the following scenario - you have to localize some software with a date in it. Thai is one of the locales. They use the Buddhist calendar which means that this year is not 2013 but it's actually 2556. That's a pretty easy thing to overlook.
... metric time -- bring on kilodays, nanodays, all of it. I can't wait another microday for this.
The list of false assumptions about time does not include one that I found in a past version of Microsoft SOAP Toolkit:
If the current year's "spring forward" is in the future, then daylight savings time is not currently in effect.
If you think that's true, check the 2013 "spring forward" date in any place where daylight savings time is currently in effect.
You merit the +4 upward moderated rating you received... good job!
APK
P.S.=> Sorry for the delayed reply, & "onwards & upwards"...
... apk
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...