When an application depends on third-party data, a developer cant expect to redesign those data structures to meet the applications needs. GPS data, for example, is one size fits all. If you want to use GPS-based location data, youll either be relying on someone elses firmware, or interpreting the Global Positioning System data structures yourself: Either way, you may overlook some of the limits of those structures. Even if theyre not concealed in someone elses code, youll never go through the process of deciding what those limits should be—and that means you have to make an extra effort to think about the implications of going beyond those limits.
When developers dont look inside their data, their users wind up looking pretty mad. A little more than a week ago, an 8-bit counter field in the GPS Navigation Message rolled over from 11111111 to 00000000. This reset of the 256-week WNa (Almanac Week Number) field, as with the 10-bit GPS Week Number or the two 8-bit fields used for Leap Second corrections, must be interpreted correctly by GPS receivers or by downstream processing software. It seems like more than coincidence that some popular models of Motorola cellular phones promptly lost their Assisted-GPS location capabilities.
Follow-up statements about the reported bug fix have been vague, as of the time this was written, as to whether or not a WNa overflow was the problem, but it would not be the first time that this kind of bug has bitten. Some Motorola GPS receivers, for example, jumped ahead by an extra day at midnight last November 27, falsely indicating a date of November 29 until one second later, when they corrected themselves to indicate November 28. I invite you to think about the things that could go wrong during a long, long, 1000-millisecond period when a system believes that the present real-world time is one day later than it actually is.
What was the problem? There had been a span of more than 256 weeks without a Leap Second event. This is a pure Y2K-style problem, and we know how to address such problems, but first we have to realize that they exist—and Y2K was easy to predict, compared to some of the more subtle problems of this kind.
During Javas early years, I found some other bizarre examples of different decisions about how to handle date/time wraparounds. At one point, for example, Suns version of the Java class Date would wrap around to negative time, interpreting "midnight plus 128 seconds" as 11:57:52 p.m. on the date before. Microsofts version of Date did not have this behavior, so you couldnt even depend on it as a weird but deterministic bug.
Other applications, like Mathematica from Wolfram Research Inc., correctly handle anything that I throw at them: 47 oclock on February 28, for example, correctly comes back as 23:00 hours on either February 29 or March 1, depending on the year. This reliable robustness makes loop statements much easier to write, when I want to model a series of events that spans date boundaries.
Almost five years after the peak of concern about Y2K "wraparound" bugs, its time to wonder if software developers ever learned or are quickly forgetting the painful lessons learned. In short words, when software has to count things, it pays to think about what will happen when a data structure runs out of fingers and toes.
Software is taking on new tasks in more complex environments. Applications are increasingly dependent on data from outside sources. A growing portion of application function is defined by outsourced code or externally furnished Web services. These trends combine to create a dangerous climate for bugs. Killing them, or at least taming them, depends on relentless scrutiny of boundary conditions, and may require much more effort than we realize to find out where all those boundaries are.
Tell me what takes up your time at email@example.com.