Take Time to Look Inside Your Data

By Peter Coffee  |  Posted 2004-07-26 Print this article Print

GPS messages and other standard formats may have obscure limits and unexpected behaviors.

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 peter_coffee@ziffdavis.com. To read more Peter Coffee, subscribe to eWEEK magazine. Check out eWEEK.coms Developer & Web Services Center at http://developer.eweek.com for the latest news, reviews and analysis in programming environments and developer tools.

Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page

Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel