Forgot your password?
typodupeerror
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:
  • leap year (Score:4, Interesting)

    by d3matt (864260) on Thursday January 03, 2013 @06:41PM (#42468371) Homepage
    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!
  • The world will end on December 21, 2012 anyway.

  • Neither did Google (Score:3, Informative)

    by Anonymous Coward on Thursday January 03, 2013 @06:43PM (#42468401)

    They left December out [techcrunch.com] of Android Jelly Bean's date picker.

    • by Qzukk (229616)

      Has anyone come up with a good way to test user interfaces yet other than to have someone sit slack-jawed and wiggle everything they see on the screen for hours on end?

      • I don't know about "good" but for Android there is Monkey Runner [android.com]

        I don't think that would have saved December though.

        Maybe a unit test should assert that there are 12 items in the month list though.

      • Has anyone come up with a good way to test user interfaces yet other than to have someone sit slack-jawed and wiggle everything they see on the screen for hours on end?

        The Java Robot class is built into the standard library and can be used to control mice, keyboards, and features screenshot capability. If you can come up with a way to convert menu selections in your application into a function call like selectMonth(2013,'March'), then you compose all of the related screenshots generated together. Now your slack-jawed guy just needs to play a game of spot the differences.

        I am sure better options exist.

        • Robot is part of the awt package and thus is not supported on Android.

          http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/Robot.html [oracle.com]

          The (better IMHO) Android class would be TouchUtils [android.com]

          (Though it seems to be missing screenshot capability. )

        • My shop used Rhino (JS running in the same JVM as your Java) to write JS automated test scripts. We've got about 800 of them now, and it's awesome. We've built it to run on multiple machines, aggregate logging, report failures, all built into our nightly build with Jenkins so we sit down in the morning and there's a list of issues waiting for us on all new code builds.

      • One example for java (there are others): http://code.google.com/p/windowlicker/ [google.com]

  • by Anonymous Coward

    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? (Score:5, Interesting)

    by gr8_phk (621180) on Thursday January 03, 2013 @06:45PM (#42468431)

    Got tips for catching time/date bugs "from the mysterious future"?

    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.

    • by Tanuki64 (989726)

      Stupid copy restriction?

    • You mean outside of software like ntp, Kerberos/AD, motion calculations, astronomical calculations, GPS.

      Just to name a few things off the top of my head.

    • by Zadaz (950521)

      Why does software functionality depend on the date? Calculation issues maybe... but failure to lauch? WTF?

      Some kind of half-assed copy protection or trial use. "Dude, you totally changed the date to get around our 30 day trial! No more software for you!"

      Stupid, yes. But it exists.

    • See this link for an example: http://www.wmusers.com/forum/archive/index.php/t-5470.html [wmusers.com]

      webMethods' 'Trading Networks' B2B integration software (now owned by Software AG) used a GUID-generator routine which created 24-byte GUIDs for processing B2B documents. One of the inputs to this routine was the number of milliseconds between UTC and UNIX epoch.

      One day in 2004, the progress of time caused 25-byte GUIDs to be created. Trading Networks tried to insert these into a database column whose width was 24 byte

      • by gr8_phk (621180)
        That's so stupid. If your code is going to generate a 24 byte GUID then it should do so under any valid set of inputs to the GUID generator. In fact, if there it's even possible to generate a larger number it should be truncated to 24 just to be sure. If date and time are going into it, you have to consider a reasonable range of dates. But thanks for the example, it shows how little effort some companies put in.
    • by holiggan (522846)

      One word: DRM. I bet that some sort of validation was date-dependent and with the year rollover, it got wrecked :)

      Just my two euro-cents :)

    • by sjames (1099)

      In the case of Adobe, it is (as is often the case) the stupid license management that broke the program.

  • by Zapotek (1032314) <tasos,laskos&gmail,com> on Thursday January 03, 2013 @06:46PM (#42468457) Homepage
    ...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...
    • by Zapotek (1032314)
      Damn it! *breaking* /facepalm
      • by Qzukk (229616)

        Damn it! *breaking* /facepalm

        I bet your test system came to a screeching halt though, so it's still good!

    • funny real event: Co-worker could not get his email client to work. Connection is managed using SSL, and the tunnel setup was failing. The reported error was a certificate invalid. That didn't jive with the CA cert - it was issued a year ago and is good for like 20 years.

      After looking and looking and looking: He realized his system date was set to 1/1/1980 - his CMOS battery was dead.. Jan 1 1980 is prior to the start of the validity period for the CA cert in use.. ;)

      • Yeah, that's happened to me. Shouldn't that just work, though. I mean unless you've invented time travel, why wouldn't you accept a cert that's before its validity period? Is there a vulnerability use case that I'm not aware of?

        • by Zapotek (1032314)
          Because all it would take to break through the auth (or whatever the SSL certs were used for) would be to mess with the system clock -- could be hard, could be easy, doesn't matter, it'd be one more liability.
        • I can see it adding a little bit of security by obscurity by requiring an attacker who has acquired an expired cert to set the clock back just the right amount before using it, rather than just resetting to the middle ages. Of course, if you can set the clock on someone's machine you probably have little need to convince it to accept a bad cert ...

        • by Shimbo (100005)

          Yeah, that's happened to me. Shouldn't that just work, though. I mean unless you've invented time travel, why wouldn't you accept a cert that's before its validity period? Is there a vulnerability use case that I'm not aware of?

          If your clock is resets to 1980, you don't know which certificates have expired. If you accept all, you run the risk of accepting a genuinely expired certificate. Although it would be more helpful to have the OS report implausible dates.

    • 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 [slashdot.org]
      (It was the same vendor in both cases)

  • 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
  • 2038 (Score:4, Informative)

    by Dishwasha (125561) on Thursday January 03, 2013 @06:50PM (#42468505)

    I for one am stockpiling canned meat in my bomb shelter for 2038 [wikipedia.org]. 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.

    • by rubycodez (864176)

      the mainstream virtualization wares used at enterprise level already use 64 bit time

      some control and embedded system are more like to be troublesome, but the failures will be sporadic. stay out of your bomb shelter and laugh at the companies who lose

      • by sco08y (615665)

        the mainstream virtualization wares used at enterprise level already use 64 bit time

        some control and embedded system are more like to be troublesome, but the failures will be sporadic. stay out of your bomb shelter and laugh at the companies who lose

        You cunning son of a bitch... You're just saying that to lure me out of my bomb shelter!

    • Have your forward-date tested the edibility of your canned spam?

      If you plan to eat it in 2038, you really, really should, :)

  • . . .is a Western disease.
    • by rubycodez (864176)

      never been to Tokyo or Kuala Lumpur or Tapei? some asian societies take the concept of workaholic to the next level....

      • I was stationed out of Yokosuka for a year, where I heard the aphorism.
        Truly a different mindset.
      • by green1 (322787)

        Knowing what time it is implies you are looking for quitting time. If you work 24/7 you don't need to know what time it is!
        Now get back to work!

  • What does this have to do with Unit Tests?

  • by T.E.D. (34228)
    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.
  • 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 o

  • by LordStormes (1749242) on Thursday January 03, 2013 @07:40PM (#42469071) Homepage Journal

    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? [slashdot.org]

    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

  • 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/ [arizona.edu]

  • No one would be stupid enough to set the system clock to local time.

  • 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 compu

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

      All sane* databses store time as seconds since epoch. That's a format that can be converted to GMT without error whatever are the settings of your OS. The user interface, by the other side, rarely uses a simple format, and will often translate things wrong.

      * Yes, if your database doesn't do that, it's insane. so are its

  • 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.
    • by SkimTony (245337)

      I suspect you're thinking of PageMaker, which was replaced by InDesign. FrameMaker is a whole different popsicle stand; as I understand it, it's the difference between laying out a page, and laying out a whole book.

  • 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.
    • by jgrahn (181062)

      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.

      A good programmer would have handled it, period. As others have mentioned, there are very few excuses to handle time as anything but an offset from epoch. It's no different in the object-oriented languages I know.

      • by Murdoch5 (1563847)
        I pointed of Object Oriented languages because a lot of them have date handling that I've seen people rely on. You should never rely on a built in check to save your butt. You need to do the check yourself and handle it.
  • 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..

  • Surely you jest. Well at any rate I'm sure they'll fix it with an 857MB patch to Adobe reader.

  • 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-w [arstechnica.com]

  • 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

  • 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

Given its constituency, the only thing I expect to be "open" about [the Open Software Foundation] is its mouth. -- John Gilmore

Working...