Have any Y2010 bugs been noted yet?

Factual Questions
21

While more Unix machines have 64bit architecture, there is a compatibility issue with t_time since the data structure itself is defined as 32 bits. Whoops!

Most Unix systems and Linux now are using a 64bit t_time data structure, at least in their 64 bit library. In their backwards compatible 32 bit library, they are still using the older 32bit definition.

Fortunately, we are replacing systems faster than ever. I doubt that anyone would have a 32 bit desktop or server by 2038. Still there might be a problem for embedded systems that use Unix/Linux as their built in OS. These can be found in cable boxes, smart phones and airplane control systems.

Okay, just joking about that last one. Even these embedded systems are being replaced at a rapid rate. Still, I would highly recommend on January 19, 2038 that you take the train instead of the plane. And, wear a helmet in case anything comes crashing down from the sky.

22

Well now I have read of two 2010 bugs:

[ul]
[li]A number of bank and credit cards issued by German banks, carrying their security information on chips according to a standard called EMV rather than the old school magnetic strips, stopped working at the beginning of 2010 because a certain type of chip cannot handle the year 2010, due to a software bug. To be fixed by an ATM/mechant terminal software update (I assume the ATMs/terminals will spoof the date when talking to chips of that type) Source (German language, sorry - could not find an English-language source yet[/li][li]Some versions of SpamAssassin have a Y2010 bug [/li][/ul]

23

I’m confuzzled. How do you know it was a “real quick easy fix” if it was never fixed?

On the OP, we still see people trying to pass off two digit years in their dates, several web pages use drop down date selections that were written years ago, but the dates were hard coded and ran out after a period, so some do not have an option after 2009, until someone goes back in and hard codes new numbers. But that’s not really a 200x issue. I know i’ve written code that will run out of hard coded dates three years after I retire, not for any malicious reason, just because I got tired of writing in hard coded dates. (CNTL-C/CNTL-V in excel can be exhausting and don’t get me started on autofill)

24

Many of the fixes that were put in for Y2K were not permanent. A popular method involved a technique called “windowing”. It works like this;

My application is getting a date in MMDDYY format. At the time I was told to fix our code, it could reasonably be assumed (because of the kind of date it was) that any date where YY was greater than 50 was in the 20th century while any date where YY was less than 51 was in the 21st century. For example, 11/15/62 would be translated as 11/15/1962 while 11/15/32 would be translated as 11/15/2032. The ‘19’ and the ‘20’ are basically hard coded. This example will break on 1/1/2051.
You might ask ‘Why didn’t you fix it right, by changing all dates to MMDDYYYY format?’. Because there was a shitload to fix and limited time to do it. Also, some of the dates are not in our control (input from outside sources). There are many of these time bombs out there and some of them will undoubtedly go off. The smarter companies kept an inventory of these changes.

Edit; This was also done on older systems where it was assumed that the system would be taken out of service before the window became an issue.

25

Maybe its just me but…

I upgraded to Windows 7 from Vista a couple months ago and when I came down the morning of Jan 1 2010 my computer had ‘forgotten’ that it was connected to an external WIFI adapter. Rebooting the computer got it going again, but now it periodically either loses connectivity to the wireless hub, or says its connected to the hub but claims that there’s no internet access. Other computers in the house, including one W7 machine, have not had such problems. Mine didn’t either prior to 1-Jan.

26

Two that have affected me directly.

Symantec Endpoint Protection

Zenworks Asset Management has an issue, I just can’t locate a news article for it.

And one that I found in the news, SpamAssassin seems to be flagging all messages.

27

I’ve seen the SpamAssassin bug personally.

What really gets my goat though is that no one’s prepping yet for the Y10K bug. Why do we always wait until the last minute.

28

Some people are at least tangentially thinking about that one, PW.

29

Excellent explanation. The really interesting part of this is each app from each vendor (or each internal app) uses a different window. So instead of one massive world-wide surprise when 12/31/1999 became 1/1/2000, we’ll be enjoying mini-surprises every Jan 1st in various spots throughout the IT ecosystem. And they won’t necessarily be happening on the round numbers like 2010 or 2020 or …

Right now if you enter “01/01/30” into a cell in Excel 2003, it assumes you mean 1930. If you enter “12/31/29”, it assumes you mean 2029. So they are windowing the input, even though they aren’t windowing the values actually stored in the cell.

This difference is gonna start biting naive users soon enough.

30

Looks like the Germans are in for some grief with their ATM cards for a little while.

Link

31

Another variant of the windowing technique is to use a rolling window where the window changes with the current year, say 60 years back to 39 years forward. So, for example, right now we consider “50” - “99” to be 20th century, In 2011, we start considering “51” - “99” to be the 20th century. This has the advantage that it will continue to work indefinitely for many applications which never have to deal with a date that many years away from the present.

32

Ahh, Y2K; I was lucky enough to handle Y2K compliance for embedded SW running on a telecommunications product deployed worldwide in 1999. Besides the 010100 hysteria, I recall two other rollover bugbears:

9/9/99 - A lot of folks thought that this date would crash older systems where 9999 was used as a data input to terminate a program. This was ridiculous–I took all of 5 minutes to check our code for this, and I can’t believe this bug affected anyone–but as I recall it was taken seriously.

GPS epoch - In the GPS system, each satellite sends time coded as an offset from January 6th, 1980. This code includes a 10-bit “week number” indicating the number of weeks since this start date. So on a certain date in August of 1999, the GPS system rolled over the week number from 1,023 to 0–in technical terms we entered a new GPS epoch.

This particular bug also ended up having no effect on our code (the product didn’t use GPS time), but I gained an appreciation for the “windowing” mentioned above. Ideally GPS_based SW should store the last-known date before powering off, then when it pow-rs on and reads GPS it can interpret the week number correctly (e.g. we are currently in week 541, current date 1/5/2010 is saved, SW is powered off for five years, turned on and GPS week number is read as 800; SW should be smart enough to place this in 2014, not 1995. Course this doesn’t work if the SW is off for 1,024 weeks, but…). In practice there are still problems with this approach; mis-read GPS time once, save it, and the device could “jump” to another epoch and be stuck 19.5 years in the past/future. Trust me, I’ve seen it, and customers get quite irate when, say, airtime minutes expire because the device they were using thinks its 19 years in the future, or they can’t get new units because it’s stuck in the past and thinks the units shouldn’t be activated for another two decades.

But altogether, I really didn’t have much to worry about with Y2K; I spent maybe a day reviewing code with engineers, another day or two testing in the lab, and perhaps fifteen minutes on the phone with a colleague in Australia on New Year’s Eve 1999, since that was the earliest site where our product would see the year 2000. It worked flawlessly, and I pocketed an extra $1,400 for working that date. Of course that was when the tech business was hemorrhaging money…

33

I’m a software developer and I have two comments:
[ul]
[li]Apathy wasn’t the main cause of the Y2K problem. The problem was a constraint in languages and systems designed in the 50’s and 60’s (mostly in COBOL). At the time the constraints made sense. Newer languages and systems didn’t have the constraint and so the Y2K bug was minimal.[/li][li]In the rare case where a Y2K-type bug is knowingly implemented it still might make sense. The cost of bullet-proofing code for an error that might occur in 50 years might be more than the cost of fixing it. I.e. *COST( bullet-proof ) > COST( cheap ) * P( software still in use ).[/li][/ul]

34

Another issue: this time in SAP - all releases have a spool request issue that sets their date to the year 2100

35

A teacher I know had a hard time doing report cards this week because the grading program thinks the attendence records for 2010 are for 1910. It’s a pretty crappy program all around though, I don’t know why they use it.