Upcoming Y2K-like problems

The world’s computer systems kept working on January 1, 2000 thanks to billions of dollars spent on fixing old software. Two wrong conclusions to draw from Y2K are

  1. The programmers responsible for Y2K bugs were losers.
  2. That’s all behind us now.

The programmers who wrote the Y2K bugs were highly successful: their software lasted longer than anyone imagined it would. The two-digit dates were only a problem because their software was still in use decades later. (OK, some programmers were still writing Y2K bugs as late as 1999, but I’m thinking about COBOL programmers from the 1970’s.)

Y2K may be behind us, but we will be facing Y2K-like problems for years to come. Twitter just faced a Y2K-like problem last night, the so called Twitpocalypse. Twitter messages were indexed with a signed 32-bit integer. That means the original software was implicitly designed with a limit of around two billion messages. Like the COBOL programmers mentioned above, Twitter was more successful than anticipated. Twitter fixed the problem without any disruption, except that some third party Twitter clients need to be updated.

We are running out of Internet addresses because these addresses also use 32-bit integers. To make matters worse, an Internet address has an internal structure that greatly reduces the number of possible 32-bit addresses. IPv6 will fix this by using 128-bit addresses.

The US will run out of 10-digit phone numbers at some point, especially since not all 10-digit combinations are possible phone numbers. For example, the first three digits are a geographical area code. One area code can run out of 7-digit numbers while another has numbers left over.

At some point the US will run out of 9-digit social security numbers.

The original Unix systems counted time as the number of seconds since January 1, 1970, stored in a signed 32-bit integer. On January 19, 2038, the number of seconds will exceed the capacity of such an integer and the time will roll over to zero, i.e. it will be January 1, 1970 again. This is more insidious than the Y2K problem because there are many software date representations in common use, including the old Unix method. Some (parts of) software will have problems in 2038 while others will not, depending on the whim of the programmer when picking a way to represent dates.

There will always be Y2K-like problems. Computers are finite. Programmers have to guess at limitations for data. Sometimes these limitations are implicit, and so we can pretend they are not there, but they are. Sometimes programmers guess wrong because their software succeeds beyond their expectations.

4 thoughts on “Upcoming Y2K-like problems

  1. Excellent post. One correction though: the “twitpocalypse” did not affect the twitter service itself, it only affected certain twitter apps which had been written incorrectly.

    Anywho, this is a very common problem when engineers decide how much margin they need to leave and choose a figure that’s low instead of high. One of the most common examples of this is insufficient lengths for name and address fields. Anyone with a first name over 10 characters long has probably seen this in action. It’s almost sad how often people screw this up.

    The really interesting thing about running out of IP addresses is that we’ve been running out for about 10 years now, and despite massive growth in the internet we’ve still, somehow, managed to come up with ever more clever efficiencies. It looks like, finally, IPv6 will become the norm, but one wonders whether it would be possible to stick with IPv4 indefinitely.

    Other interesting Y2K like problems:

    ISBN numbers for books used to use only 10 digits, since 2007 new ISBNs have 13 digits (both include a check digit).

    Vehicle Identification Numbers (or VINs) are running out. The existing system was only planned for a 30 year lifetime (until 2011). Even though it uses 17 digits most of the digits are used for descriptive data rather than serial number info (e.g. manufacturer, origin country, make and model, etc.)

    Also, don’t forget the original y2k problem! One of the more common ways of “fixing” the y2k problem was to introduce a sliding window such that 2 digit years less than (say) 30 translated to 20xx, whereas higher 2 digit years translated to 19xx. Some of these solutions are still in place out there, and eventually they will reach yet another rollover period and break if they aren’t fixed yet again.

  2. The Unix date problem’s already hit some software. Think of 30 year mortgages. (Fortunately, in most 64 bit implementations, time_t is 64 bits. )

  3. The thing about Y2K type problems is that they occur everyday with software development. Y2K bugs come with the domain of software development, where the environment around you is always changing and what was a reasonable assumption/requirement yesterday cannot apply today.

    What separates a Y2K bug from a regular bug is the fact that there is an external factor (e.g. a specific date reached) and an unpredicted factor (e.g. the software would have been upgraded by that date).

    Most software is not written using architecture independent variables like size_t and time_t. If you ever see a static_cast from a `size_t` to a `UINT`, you’ll be staring at a loss of data when size_t is 8 bytes and UINT stays at 4 bytes. In fact, one of the Y2K type problems that is occurring now is the move from 32-bit to 64-bit commercial software.

    Consumers are purchasing 64-bit machines to replace their old 32-bit machine, and will notice a large increase in performance from software that is designed to take advantage of 64-bit machines and multiple cores. Vendors that don’t make their software work well on these machines will be faced with a competitor who will.

  4. Small correction: a signed 32-bit time_t will overflow in 2038 not to zero, but to approximately minus two billion seconds before the epoch, i.e. it will “be” December 13, 1901.

    An unsigned 32-bit time_t would overflow on Feb 7, 2106, if I’m not mistaken. I don’t think any systems use an unsigned time_t.

Comments are closed.