Y2.01K

After our recent discussion of decimal/hexadecimal confusion at the turn of 2010, alphadogg writes in with a Network World survey of wider problems caused by the date change. "A decade after the Y2K crisis, date changes still pose technology problems, making some security software upgrades difficult and locking millions of bank ATM users out of their accounts. Chips used in bank cards to identify account numbers could not read the year 2010 properly, making it impossible for ATMs and point of sale machines in Germany to read debit cards of 30 million people since New Year's Day, according to published reports. The workaround is to reprogram the machines so the chips don't have to deal with the number. In Australia, point-of-sales machines skipped ahead to 2016 rather than 2010 at midnight Dec. 31, rendering them unusable by retailers, some of whom reported thousands of dollars in lost sales. Meanwhile Symantec's network-access control software that is supposed to check whether spam and virus definitions have been updated recently enough fails because of this 2010 problem."

Comments

Have I not heard this before?

[bezenek]

Didn't I hear this before? I remember people talking about scamming banking systems via the confusion caused by 2010.

Does anyone remember this well enough to dig up the article?

Thanks (and lazy),
Todd

Re:Have I not heard this before?

[Arthur Grumbine]

Didn't I hear this before? I remember people talking about scamming banking systems via the confusion caused by 2010.

Wait a second... isn't that the plot from Superman IV?

idiocy? Incompetence?

[rueger]

How on earth can things like this happen? After the Y2K debacle how can anyone
not anticipate and extensively test for future dates?

Is this sheer utter incompetence, or just a total lack of intelligence?

Yee Gods!

Re:idiocy? Incompetence?

[MichaelSmith]

Because everybody forgot about Y2K on Jan 1 2000. Planes didn't fall from the sky, remember (well not immediately, anyway).

Re:idiocy? Incompetence?

[Anonymous Coward]

Is this sheer utter incompetence

Sounds good! Tastes even better!

Re:idiocy? Incompetence?

[xous]

This is because they let people that shouldn't be anywhere near a production system write software.

Almost all of these issues can be attributed to developers rolling their own date handling functions or misusing built-in functions.

I'd blame some of it on retarded user interfaces that accept two digit year values.

DO NOT REINVENT THE WHEEL!!

Re:idiocy? Incompetence?

[the_humeister]

Wait until Dec. 31, 9999. Watch as people panic about there being 5 digits in the year and how programs were only written to accommodate 4 digit years for the past 8000 years!

Re:idiocy? Incompetence?

[TheGratefulNet]

Is this sheer utter incompetence, or just a total lack of intelligence?

you phrase that question as if it can't be both...

Re:idiocy? Incompetence?

[jlarocco]

100% incompetence.

I would bet all the money I have that 99.99% of these problems are caused by people not taking the time to learn the standard library of whatever programming language they're using. For some reason there's a gut instinct among programmers that they have to write all date processing code themselves. I can think of 4 separate occasions, off the top of my head, where I've replaced dozens of lines of sketchy, hand roled, date formatting code with a single call to strftime.

Re:idiocy? Incompetence?

[MichaelSmith]

Wait until Dec. 31, 9999. Watch as people panic about there being 5 digits in the year and how programs were only written to accommodate 4 digit years for the past 8000 years!

They are going to have thaw out a lot of old cobol programmers.

Re:idiocy? Incompetence?

[mlts]

Its neither. It's ROI and worrying about this quarter's earnings over anything else, pure and simple. Because there isn't any primary returns from finding date errors in the future, businesses just won't plunk down funds to fix them, and will reactively fix problems when they happen. I see this a lot in businesses, and not just the big boys. Plenty of SMBs also are not interested in hearing about anything they need to spend their money on, but stuff that has a positive return. They would rather forget about time issues. When zero hour happens, most feel that they can hire a ton of consultants to fix any problems that arise, even though it costs way more than if it was fixed before stuff failed.

Just the same with computer security because to a typical MBA++ PHB, security gives no financial gains. I've heard so many times, "I'm not worried. If I get hacked, I'll just call the Geek Squad guys and they will fix it."

Re:idiocy? Incompetence?

[Evil Shabazz]

At the Bank of Germany, we're not happy until you're not happy.

Re:idiocy? Incompetence?

[LoRdTAW]

Hmmm so the 9/11 hijackers were Y2K bugs then? We better keep an eye out for more aircraft bugs on Sept 11 2011 .... holy shit there is an 11 in 2011 AND 9/11! ZOMG!

Re:idiocy? Incompetence?

[Anonymous Coward]

DO NOT REINVENT THE WHEEL!!

The catchphrase of the "it's old code so it's good code" fools.

Re:idiocy? Incompetence?

[Anonymous Coward]

I don't think he specified exclusive-or. Checking these conditions would still return true if both were individually true.

Re:idiocy? Incompetence?

[Anonymous Coward]

I call it job security.

Re:idiocy? Incompetence?

[kestasjk]

Ah nothing like a 9/11 joke to brighten my day

Re:idiocy? Incompetence?

[darkpixel2k]

Because everybody forgot about Y2K on Jan 1 2000. Planes didn't fall from the sky, remember (well not immediately, anyway).

Yes. I anticipated this. I now store all my dates much like the Unix epoch, except I store it in a 1 gigabit integer field (f*ck 64-bit integers) that counts the number of seconds since midnight January 1st, 50,000,000,000^1024 years ago.

We should be safe from now until the universe collapses, Jesus comes back, Allah blows us all up, or the Great Green Arkleseizure wipes his nose.

Oh--and you do have that new holographic storage tech in your laptop, right? You'll need a few exobytes just to store the timestamps on all your files...

Re:idiocy? Incompetence?

[thsths]

> At the Bank of Germany, we're not happy until you're not happy.

Indeed. They even said if the cache machine in your branch did not work and you had to get money from a competitor, you will not get the fee reimbursed at most banks. So far only one bank has promised to pay them back.

Re:idiocy? Incompetence?

[HuckleCom]

The -REAL- Y2K is the unix epoch - where HARDWARE base storage chips that keep time (really just a count of all the seconds since the beginning of the epoc) will essentially overflow because they can't store a number that large.

Re:idiocy? Incompetence?

[JustinKSU]

A little bit of both!

We have actually had TWO different Y2K10 problems at our job. One was related to someone setting certain rules to expire in 2010, because, you know, it was so far off in the future they wouldn't be working here anymore.

The other bug qualifies as complete incompetence on the developer. We contracted another company to write some software to print barcode labels. They encoded pipe delimited values including a date. In order to save digits and thus reduce the size of the barcode they decided to take the year and append the Julian day. For example Jan, 6th of this year would be stored as 2010006. The problem was that they didn't feel that it was necessary to use four digits for the year. Which is understandable, but apparently TWO digits for the year was too much as well. So the end product was a one digit year ex. "0006". The code that reads the label was:
year = 2000 + barcode.left(1);

What's really scary, is that this code had to have been written post Y2K.

The worst part of the whole thing is that we have to go back to the contractor to fix the problem which is going to cost us $$$ beyond the lost revenue of downtime.

Now both of these problems have nothing to do with 2010 specifically, but it just shows how short sighted developers can be.

Re:idiocy? Incompetence?

[ozmanjusri]

They are going to have thaw out a lot of old cobol programmers.

True.

We should start freezing them now, just to be sure.

Re:idiocy? Incompetence?

[Anonymous Coward]

Since the contractor is going to be paid a second time, I would say it demonstrates their forward planning.

Re:idiocy? Incompetence?

[w0mprat]

End of the world? I just checked my calendar, and the last day is December 31st. This has me deeply concerned.

How on earth could this happen? This is shear blistering incompetence that no one thought to include any more days past this point.

Re:idiocy? Incompetence?

[TubeSteak]

They are going to have thaw out a lot of old cobol programmers.

I, for one, welcome the Lords of Cobol.
 
/All this has happened before, and all of it will happen again.

Re:idiocy? Incompetence?

[thorndt]

Better make sure your computer rounds that (way way down) to 13.7 billion. According to current cosmological thinking, that's when time began.

Re:idiocy? Incompetence?

[Rhaban]

How on earth can things like this happen? After the Y2K debacle how can anyone
not anticipate and extensively test for future dates?

Is this sheer utter incompetence, or just a total lack of intelligence?

Yee Gods!

Step 1: A company uses a bunch of old softwares that can't handle dates past 1999, because the year is coded with 2 digits.
Step 2: The company hires a consultant to correct their softwares.
Step 3: The consultant sees the code is a mess, and understand he won't be able to correct everything cleanly before the deadline.
Step 4: The consultant decides to call a function wherever a date is used, that changes the way dates are handled so that a year beginning by a 0 works like it is posterior to a year beginning by a 9 (or any other digit).
Step 5: ???: The consultant warns the company that a better correction must be applied before 2010, and that they should do something about it in advance, not wake up suddenly on december 12 like this year and wonder what to do. Or he keeps that for himself (after all, it won't be a problem until 10 years later, why bother?)
Step 6: Profit: The consultant gets his check and gets drunk.
Step 7: The companys does nothing to correct the problem.
Step 8: 10 years later, the Y2K bug strikes like the spanish inquisition, when nobody expects it.

Re:idiocy? Incompetence?

[wisty]

"If it's old code it's good code" is a half-decent catchphrase. "No code is good code" is better. (Or less code, if you really must code).

Re:idiocy? Incompetence?

[Monsieur_F]

"The only good code is dead code"

Re:idiocy? Incompetence?

[hydromike2]

Wait until Dec. 31, 9999. Watch as people panic about there being 5 digits in the year and how programs were only written to accommodate 4 digit years for the past 8000 years!

I wouldnt sweat the 5 dgits, we only have 2 years 350 days +/- a few hours till the earth goes back to zero(if even that, possibly even negative relative to the next sentient species that comes to be on earth)

Re:idiocy? Incompetence?

[aix tom]

That will actually be a problem in 2017 in code I wrote.

I needed to implement 3-digit inventory taking IDs in 2007, whit about 20-30 inventories taken each year. So I have a one-digit year in those IDs, and in 2017 I will have to either delete the old ones or find a new approach.

But since a few weeks all our barcode scanners also can handle letter barcodes, so I can probably push the real problem into 2043, when I'm retired. ;-P

Re:idiocy? Incompetence?

[bradley13]

Two reasons

1. Many programmers are not particularly competent. Add in the untrained people writing scripts, VBA applications, etc, who have no clue about software engineering, testing, etc. No surprise that simple errors crop up.
2. Dates are really, really horrible. If you have not had the privilege of writing an international application, worrying about different date and time representations, simultaneity across different time-zones (and the date line) - well, it's an adventure, and even careful testing may not catch everything. Gratuitous real-world example: WinXP allows users to set date-separators and the like in a way that makes unambiguous date/time parsing impossible.

Re:idiocy? Incompetence?

[gmack]

How do you explain this bug from spamassassin?

X-Spam-Status: Yes, score=6.1 required=4.0 tests=AWL,FH_DATE_PAST_20XX,
        HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY autolearn=disabled
        version=3.2.5
X-Spam-Report:
        * 3.4 FH_DATE_PAST_20XX The date is grossly in the future.

Re:idiocy? Incompetence?

[Rhaban]

WinXP allows users to set date-separators and the like in a way that makes unambiguous date/time parsing impossible.

That's a microsoft thing.
Similarly, a .xls file created with a non-english excel (we often receive such files from clients who use excel in french) uses commas as the float separator and is unreadable in another version of excel.

There are tons of similar default behaviour of microsoft softwares that makes you want to kill people as soon as you begin working internationally.

Re:idiocy? Incompetence?

[Xeno man]

How about the fear of copyright infringement or plagiarism. You grow up and go through school being told NOT to copy any one elses work, hand in your own work, you can be expelled from school for handing in work that is not yours, then one day people start telling you to stop "reinventing the wheel". There is code all ready written that does that. Copy and paste that in and your done. It's not easy to go against what a life time has taught you is wrong.

Re:idiocy? Incompetence?

[Anonymous Coward]

Y2K was accepted because ordinary people could easily understand the problem. Understanding that you can't fit four digits into a two-digit space is a lot different from understanding why 00010000b is a different number when it is treated as hexadecimal data as opposed to binary-coded decimal data.

But the BIG DEAL over Y2K was because people could make money from it. Because everyone could understand the problem with it. Managers could understand why proper testing was required, and what they stood to lose if they took a chance. The engineers already had a handle on the problem; they just didn't have the authority to get in and fix it themselves without asking for the money (and time, which is money) to do so.

No such luck with, probably, every other date-range problem we will have - except maybe Y10,000. *Maybe* 2099. But there will be problems every couple of years. 2038 will probably be the biggest date-related problem we'll ever have, but it won't be the last (or even, as of Jan 01 2010, the next).

Re:idiocy? Incompetence?

[Anonymous Coward]

Interior crocodile alligator, I drive a Chevrolet movie theater.

Re:idiocy? Incompetence?

[ComaVN]

It's not the Excel language that breaks stuff as far as I recall, but Windows' regional settings. Set your windows regional settings to France or whatever, and it should work.

At least, that is the case for csv files in Excel.

Re:idiocy? Incompetence?

[digitig]

Simple. Y2k is being delivered ten years late. People never learn about late IT deliveries!

Re:idiocy? Incompetence?

[Rhaban]

Thanks for pointing that out, I'll try to remember that next time i'm faced with this problem.

Re:idiocy? Incompetence?

[melmut]

I don't think you any schools teaches not to reuse things. They teach you not to use things you aren't allowed to use. Did they tell you to build your own computers and to make your own transistors? Think about what you were taught, don't just blindly repeat what you thought you heard.

Re:idiocy? Incompetence?

[melmut]

It isn't windows. It is the fact that you insist using a format which doesn't make date representation unambiguous (csv). You won't have any problem using an excel file: it will be rendered using the right regional settings you chose, whatever regional settings were used when the file was created.

Re:idiocy? Incompetence?

[Hurricane78]

Aaah, I always wondered, that if Galactica was an infinite loop, then how did it all start. NOW I know.

I wonder if Cylons crash on round date values. ;)

Re:idiocy? Incompetence?

[Hurricane78]

That’s more of a C programmer’s disease. Because it came with next to no libraries. I mean, the environment is not even developed to a point where basic memory management has a sensible abstraction from hardware. (No, you don’t need to hand-roll that. You just need to think harder, on how to generalize that thing.)

Re:idiocy? Incompetence?

[jimicus]

Dates are really, really horrible. If you have not had the privilege of writing an international application, worrying about different date and time representations, simultaneity across different time-zones (and the date line) - well, it's an adventure, and even careful testing may not catch everything. Gratuitous real-world example: WinXP allows users to set date-separators and the like in a way that makes unambiguous date/time parsing impossible.

Which is why you don't do that. You let standard library functions (which were mostly written years ago and have been tested far more extensively than any of your code is likely to be) handle it.

And where this is impossible, you don't even attempt to parse dates. You work purely on something like "number of seconds since the epoch" and only turn it into a human-readable date just before you show it to a human.

Really, the cases in which you're likely to need to parse a date in the real world are few and far between.

Re:idiocy? Incompetence?

[Anonymous Coward]

You missed one, i think you meant 9/11/11: THE SEQUEL.

Re:idiocy? Incompetence?

[JaredOfEuropa]

Re. point 1: Coding is complex, and newbies turning out poor code doesn't mean they are morons or poorly trained. A lot of the finesse of proper software engineering comes through hard-won experience, and quess what: rarely do we give those newbies a chance to gain that experience.

What I am talking about is mentoring and code reviews, two things that seem to have gone the way of the dodo. "Catch errors early" has always been a good coder's maxim; but there really is no excuse to have a newbie's code go unscrutinised. Catch their errors early so you can both have a good laugh about it, and he can fix the error at his leisure. If such errors come up during final testing (or worse: after release), you're too late. Instead of a valuable lesson you'll have an expensive embarassment on your hands.

Re:idiocy? Incompetence?

[ais523]

Personally, I blame it on bad reverse-engineering. 9 looks the same in binary and binary-coded-decimal (the bit pattern for each is 00001001), but the bit pattern for 10 in binary-coded-decimal (00010000) is the same as the bit pattern for 16 in binary. I imagine what's going on here is people guessing at a protocol and not having enough information to distinguish binary from BCD. (If they do that because the protocol isn't available, it's forgivable; if they do it because they're too lazy to look it up, it's incompetence.)

Re:idiocy? Incompetence?

[ais523]

As reported on Slashdot earlier, it was using a regex for date handling, that had the year 2010 hardcoded. (The irony here is that the SpamAssassin people had noticed in time and changed the date to a hardcoded 2020 instead, but forgotten to put the fix into the update channels, so nobody got it until after 2010 had already started. Of course, this is still the wrong way to do things...)

Re:idiocy? Incompetence?

[Anonymous Coward]

Lighten up loser.

Re:idiocy? Incompetence?

[Anonymous Coward]

Incompetence. Thankfully it's limited to cards made by one company. Not so thankfully, that company supplies 40% of all debit cards in Germany. (Insert sideswipe about monoculture here.) Finally and funnily, that company is French.

Google translation of the news here: http://translate.google.co.uk/translate?u=http%3A%2F%2Fwww.spiegel.de%2Fwirtschaft%2Funternehmen%2F0%2C1518%2C670400%2C00.html&sl=de&tl=en&hl=&ie=UTF-8

Re:idiocy? Incompetence?

[Mikkeles]

I think it's because the code was created here

Re:idiocy? Incompetence?

[vadim_t]

Actually, no. In Excel, formula names are localized, so SUM becomes SUMA in spanish. And it's not automatically converted when you open a foreign document.

Re:idiocy? Incompetence?

[jargon82]

For your second point, does it really matter? Programmers will rarely if ever get dates, no matter how hard they try....

Re:idiocy? Incompetence?

[Anonymous Coward]

Remember last year when we got past 1 000 000 000 s since the epoch... And that some programs could not handle this.

Re:idiocy? Incompetence?

[Anonymous Coward]

CSV export in Microsoft products seems to be universally fucked -- using presentation settings in a export/import format sounds odd.

The same thing happens when you export CSV from Outlook (or at least did back when I needed to work with that POS): the geniuses decided to use translated column titles in the files. Anyone who wants to read those files needs to be able to recognize any and all localized data field names in all Outlook versions (yeah, they change) -- that is Microsoft interoperability in a nutshell: The data is there in theory but it's made so difficult to use that it seems purposeful...

Re:idiocy? Incompetence?

[Anonymous Coward]

I have a hard time remembering things that didn't happen.

Re:idiocy? Incompetence?

[Hognoxious]

This is what happens when people try and shoehorn attributes into the key. Of course you'll run out - you're wasting about two thirds of your keyspace.

Let me guess, the users "needed" it like that?

Re:idiocy? Incompetence?

[valderost]

Not an issue. We'll hit the Mayan calendar 2012 bug first.

Re:idiocy? Incompetence?

[Willks]

But, it worked last year :D

Re:idiocy? Incompetence?

[Anonymous Coward]

Bad regex for the date.

##{ FH_DATE_PAST_20XX

530 header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

531 describe FH_DATE_PAST_20XX The date is grossly in the future.

532 ##} FH_DATE_PAST_20XX

Re:idiocy? Incompetence?

[The_Wilschon]

"You can have it when you pry it from my cold, dead, code." What were we doing again?

Re:idiocy? Incompetence?

[AtomicJake]

Indeed. They even said if the cache machine in your branch did not work ...

Well, this works actually very well. The machine is caching all the money ...

Re:idiocy? Incompetence?

[Anonymous Coward]

Date processing is so complicated that only a fool would try to code his own library. If there isn't a well-debugged one for the language you're using, find a way to interface to the date functions of your operating system instead of writing your own.

Re:idiocy? Incompetence?

[stesch]

Because people still insist in using their old and silly date format everywhere. dd.mm.yy, dd/mm/yy, mm/dd/yy.

There's an international format called ISO 8601, which is accepted in almost every country around the world. yyyy-mm-dd with 4 digits for the year.

If such a date format would be common, nobody would even think about using only 2 digits (or less) to save a date. And no, 2010 wouldn't be interpreted as 2016. It would be wrong from the very beginning if somebody wants to interpret a BCD number as a hex number.

Implementation of the ISO 8601 Standard Around The World, including Europe, Germany, USA.

Re:idiocy? Incompetence?

[MrKaos]

Because everybody forgot about Y2K on Jan 1 2000. Planes didn't fall from the sky, remember (well not immediately, anyway).

I've been confronted with the idiot at dinner(s) who says "what about that Y2K bug - what a load of crap that was, nothing happened". I gently remind them that a lot of people worked pretty hard to make sure nothing happened. Maybe this time around there won't be any budget to handle it. Guess we may find out on the 10/10/2010.

Re:idiocy? Incompetence?

[melmut]

They are actually converted in worksheets, not in vba code where you should use the english names in all cases.

Re:idiocy? Incompetence?

[Anonymous Coward]

I don't think you any schools teaches not to reuse things. They teach you not to use things you aren't allowed to use. Did they tell you to build your own computers and to make your own transistors? Think about what you were taught, don't just blindly repeat what you thought you heard.

I beg to differ. When I have to explain to my parents that it's okay for them to copy their CDs onto their computer, somewhere along the line the truth got blurred. Same with netflix streaming, "Why don't we have to pay each time we watch the movie?" Because netflix has a contract that doesn't make you. "So is netflix breaking the law then?" Baffling.

Re:idiocy? Incompetence?

[Anonymous Coward]

There are reasons of business and budget that trump incompetence, but your post reminded me of a story.

Technical background: I worked in VAX/VMS, where dates were stored as binary but commonly displayed as dd-mmm-yyyy, such as "01-Jan-2000".

Once upon a time, there was an Oracle DBA, whose primary claim to fame was being female and good looking in a line of work where such attributes were uncommon. She applied for a job in my IT department and we interviewed her. Although we found her visually refreshing, her technical skills were lacking. So I promoted an existing staff member into the DBA position. The candidate we passed on landed at a nearby IT shop. Later on, we had a collaborative project with that other IT group. My DBA (the one I promoted) drops into my office...

DBA: "You gotta see this! Remember Ms. xxxxxx? You were right. She built a database where all of the date fields are STRINGS!"

[DBA goes on an on about how wrong that is, but misses the real implications]

ME: "Do you know what the funny part of this is?"

DBA: "No."

ME: "She just made April Fools Day the first day of the year. In fact, years don't matter all that much, since they are relegated to the tail end of the string. Any select statement that sorts by one of those string/date fields is going to give you some fascinating results! As of now, the calendar is April, August, December...."

[Laughter for the rest of the afternoon]

Re:idiocy? Incompetence?

[Dan541]

How on earth can things like this happen? After the Y2K debacle how can anyone
not anticipate and extensively test for future dates?

We'll worry about that when we get to it.

Re:idiocy? Incompetence?

[Dan541]

How on earth can things like this happen? After the Y2K debacle how can anyone
not anticipate and extensively test for future dates?

We'll worry about that when we get to it.

True story

Re:idiocy? Incompetence?

[Wisconsingod]

I would bet all the money I have that 99.99% of these problems are caused by people not taking the time to learn the standard library of whatever programming language they're using.

I'll take that bet, and you can send me a cashier check.

The bulk of the 2016 bug was due to a miscode in a library of microsoft software, that was used by various systems, notably Windows Mobile 5.1+, EFTPOS systems in Austrailia, etc. Bugs exist in all aspects of code, and even standard library functions. The problem is when the bug is in the library, it has widespread effects around the world. The benefit is that a single fix can be coded, and then rolled out to everyone using that library.

Re:idiocy? Incompetence?

[zorro-z]

As I tell my wife virtually every day, never ascribe to anything else that which can be ascribed to human stupidity.

Re:idiocy? Incompetence?

[Anonymous Coward]

if they do it because they're too lazy to look it up, it's incompetence

And if they do it because the standards organisations want to charge large sums to read their documents and there is no budget for that, what does that count as?

Re:idiocy? Incompetence?

[Anonymous Coward]

Why is 0.818181818181818 funny?

Re:idiocy? Incompetence?

[Teancum]

Amen this this sentiment. The effort to make sure that the Y2K bug didn't cause more havoc and mayhem is precisely due to the herculean effort on the part of hundreds of thousands of programmers who worked overtime to see that it didn't happen.

I had the cell phone for my company to receive the complaints from customers seeking an engineering solution to fixing any potential problems on the night of December 31st, 1999. The company CEO had this number on speed dial for some very high end clients. That I got through the night with some excellent sleep is a testament to the work that did happen was well done.

It turned out for the company I worked for, there was a Y2K bug that did get missed, but it was relatively minor and only impacted the error logging system. Even funnier was that particular system had only been developed six months earlier, by a programmer who clearly should have known better. The date being logged was recorded as the year "19100" instead of 2000.

I'm far more worried about the 2038 Unix overflow bug, which is a much harder bug to try and root out of systems. We have 18 years to fix that bug, but I'm mainly worried that legacy applications on archaic computers used in situations that has no budget is where it will be the largest problem. Unix boxes in particular are known as workhorse computers that can be neglected and ignored... unlike a Windows computer that will most certainly be in the recycling bin within 18 years.

Also, one of the typical "fixes" for the Y2K bug was to set an arbitrary "century window" on the software.... with sometimes random intervals for when this window actually falls. Instead of Y2K biting you all on the same day, it will happen as a class of failures on random dates when some major epoch happens.... such as 2010. So for me, this isn't even news as this is something I'm expecting. 2020 is going to be another year to watch for similar bugs, and 2040 is going to be a particularly ugly year as 1940 was set as a common century epoch point for a great many companies. 1970 was more common, but I hope that the Y2K bug is finally fixed by 2070.

Re:idiocy? Incompetence?

[Yvan256]

Alright everyone, listen up! The only good code is 3735929054, Monsieur F. said so!

Re:idiocy? Incompetence?

[Anonymous Coward]

Bad time to freeze COBOL programmers. Many businesses are starting to figure out that their old COBOL and CICS stuff works, and their new Java, .NET, and XML crap doesn't when replacing an existing system. It *DOES* work in making those legacy systems more accessible.

Re:idiocy? Incompetence?

[Anonymous Coward]

I wrote some licensing code that expires in 2017, for basically the same reason - just a single digit for the year. I can only hope that the copious design and meeting notes and code comments will help someone patch the problem before that date rolls around, if any of the code is still in use.

Re:idiocy? Incompetence?

[Anonymous Coward]

Why did he include a year at all? He could have been paid yearly!

Re:idiocy? Incompetence?

[Teancum]

If you have ever worked with bloated or corrupted libraries, there certainly is a reason to "reinvent the wheel" from time to time.

Then again, it takes a very competent developer to know the difference between what is a bad library function and what is simply poor design that doesn't take into account all of the potential variables and what their valid ranges might be. Thinking that your program or software will only be used for x years is what caused most of the Y2K bugs in the first place, and similar bugs like this one in 2010.

My point is that using a library function is fine, but using a library that loads an extra meg of code for something that is a three line function is not an efficient use of software. This is precisely why Windows no longer even fits on a DVD disc any more, and they are moving on to Blu-ray discs for distribution.

Re:idiocy? Incompetence?

[IICV]

I know, we need more of them. It was traumatic when it happened, but seriously - it's been nearly a decade at this point. It's no longer too soon.

Re:idiocy? Incompetence?

[ozmanjusri]

Bad time to freeze COBOL programmers.

Shhhh.

I need a new air conditioner.

Re:idiocy? Incompetence?

[Anonymous Coward]

Is this sheer utter incompetence, or just a total lack of intelligence?

Neither, Europe just took a fix on fail approach to Y2K so we didn't spend 300+ billion dollars preemptively, bugs like this come up and are fixed in due time, the total cost will still be less than that of "solving" the y2k problem.

Re:idiocy? Incompetence?

[Anonymous Coward]

This comment is made of win.

Re:idiocy? Incompetence?

[Anonymous Coward]

...because current cosmological thinking has finally figured out when time really began, or has anything the fuck to do with how I should date my files?

They’ve been wrong every time they opened their mouths. Every time they have revised the age of the universe, it was suddenly the “correct” age, until it wasn’t again.

When it comes to storing the dates of historical events in the recent past and foreseeable future, it makes a hell of a lot more sense to base it off the time when some dude probably really lived, give or take thirty years, vs. when the universe supposedly began, give or take a few billion years, and back when there was nothing else to bother putting a date on anyway. And that’s not saying much.

Re:idiocy? Incompetence?

[Hatta]

The worst part of the whole thing is that we have to go back to the contractor to fix the problem which is going to cost us $$$ beyond the lost revenue of downtime.

Do you not have legal recourse against the contractor who sold you obviously broken software?

Re:idiocy? Incompetence?

[clone53421]

It’ll be a cold code in hell before that happens! I have no idea!

Re:idiocy? Incompetence?

[clone53421]

Exactly.

Re:idiocy? Incompetence?

[gid]

Good fucking grief, I wish people would fix it correctly and just use the a full 4 digit year already then this wouldn't happen, and add an extra 19 or 20 before a 2 digit year as needed in the data itself. Of course then we'll still have a year 10,000 bug, but that's ok, it's an SEP.

Re:idiocy? Incompetence?

[noidentity]

Yeah, so with the year 2000, we had ALL FOUR digits changing: 1999->2000, so any assumptions about the leading three being fixed would be broken. But a problem when the freaking tens digit increments?!? That's amazing carelessness. "Bah, the ones digit will never generate a carry in my lifetime!"

Re:idiocy? Incompetence?

[mangobrain]

The only good code is my code.

(No, that's not the kind of thinking that got is into this mess; clearly everyone else's code is what did that!)

Re:idiocy? Incompetence?

[fishthegeek]

So say we all.

Re:idiocy? Incompetence?

[Rich0]

Yup. At a conference I heard somebody say that "the only smart code is a dumb code" - I've been convinced this is right ever since. EVERY smart coding system I've run into at work has caused untold pain when something that would "never" happen, happened...

Re:idiocy? Incompetence?

[clone53421]

Similarly, a .xls file created with a non-english excel (we often receive such files from clients who use excel in french) uses commas as the float separator and is unreadable in another version of excel.

That’s not even true. Maybe you meant .csv files.

I’ve created .xls files on a computer with German regional settings (comma for the decimal point, dot for the thousands separator) and moved it onto a computer with normal US regional settings. It worked perfectly fine.

It even converted all my formula cells... on the German settings, semicolons are used to delimit function arguments, and commas are used for hard-coded floats. E.g. if with the US settings you’d use
=IF(A1>0.5, 0.5, A1)
with the German settings you’d use
=IF(A1>0,5; 0,5; A1)
It did all of the conversions automatically.

In a .csv file of course everything is stored as human-readable ASCII, so you’d have to change your regional settings, open it, and save it as an .xls, which should then be portable (independent of your regional settings).

Re:idiocy? Incompetence?

[Rhaban]

My mistake, it must have been .csv files. doesn't change a thing about my hate for excel.

Re:idiocy? Incompetence?

[mangobrain]

But what moron would use BCD as a format for integer storage/transmission? It might be easier to perform certain operations with, but as a storage format it's just unnecessarily wasteful. Given that plain old binary can store greater ranges with the same number of bytes, I'm struggling to think of any reason why any protocol or file format needing a fixed width integer field should use BCD instead.

If you can present a modern valid use case, please do; but my current impression is that BCD smells of obsolescence. (Needing to work with existing file formats/protocols doesn't count; whoever designed the format/protocol in the first place had better have a good reason for doing it that way.)

Re:idiocy? Incompetence?

[Gunstick]

if the code had been fixed in 1999 using reverse engineering, the developer should have seen that the field says 99 and not 63
So if 99 means 1999 then that 99 must be BCD.
If of course the developer has never heard of what BCD is (most high level languages do not have that concept and today you only learn this stuff at school) then it's no suprise that he passed over this $99 representing 1999. Never questioning why he has to modify the code as $99+1=$9A and that would be fine for 2000...

On another note, some programs were indeed fixed like that. The BCD field, in 1999 was defined as hexadecimal number of years since 1846 ... This works fine until 2102

Re:idiocy? Incompetence?

[Dreadneck]

Is this sheer utter incompetence, or just a total lack of intelligence?

you phrase that question as if it can't be both...

I refer to the intersection of the two as the Federal Triangle.

Re:idiocy? Incompetence?

[Anonymous Coward]

I think alot of that could be from VB programmers. Dear lord, the crap that VB puts you through. Locale specific date formatting and such is a bitch. And some people still do some batch programming. The horror.

Re:idiocy? Incompetence?

[maxume]

I would go so far as to frame it in terms of csv being a convention rather than a format.

Re:idiocy? Incompetence?

[SnarfQuest]

But, according to all the experts, you only need it to last till 2012.

Re:idiocy? Incompetence?

[hydroponx]

<quote><p>You missed one, i think you meant 9/11/11: THE SEQUEL.</p></quote>

I think you meant The Sqeakquel; I know I know, I'm going back to my cave now ....

Re:idiocy? Incompetence?

[dotgain]

It came from the common way of representing decimals in Electrical Engineering - BCD

Numbers were often driven directly to 7-segment displays, or set by groups of dials, each with its own decimal place. It avoid a lot of complication to use nibbles with a BCD code, particularly if only used for a counter an no arithmetic as such. Accordingly, the two CPUs I'm most familiar with: Z80 and m68k - both have instructions for adding and subtracting BCD values - often these would have been written directly to hardware registers.

In the case of every arcade game I have reverse engineered, the player's score and all the high scores (among many other things) have without exception been stored as BCD. This is because each digit will later be used as a lookup value to some graphic tile-map, and it's awfully convenient to just be able to add some particular offset value to each nibble, and then copy the entire string directly to display RAM.

Given that every time a number is presented to you on a computer BCD will need to be used in some form or another, I don't agree that is 'smells of obsolescence'. Binary numbers being converted to decimal representations are the only reason we can read numbers of computers reliably.

I had pasted some code, but ran into post filter errors. Good thing those filters stop all the trolls, eh?

Re:idiocy? Incompetence?

[jbengt]

Anyone working with $s should consider using BCD.

Re:idiocy? Incompetence?

[darkpixel2k]

Better make sure your computer rounds that (way way down) to 13.7 billion. According to current cosmological thinking, that's when time began.

Yes, and some still think we have no need for dates after 12/21/2012. It's that kind of short-sightedness that will bite us in the ass when we suddenly realize that we've calculated something wrong with the decay of carbon in relation to neutron stars or whatever...and then we realize we need to adjust the beginning of the universe by a few billion years...

Re:idiocy? Incompetence?

[darkpixel2k]

But, according to all the experts, you only need it to last till 2012.

...and 640k ought to be enough for anyone.
...and IPv6 is so huge as to be nearly inexhaustable.
and I'm sure they said the same thing about IPv4 way back when...

Re:idiocy? Incompetence?

[plague3106]

Horseshit. WinXP also provides parsing methods for you to use. Even better, in .Net, you specify your culture, parse the date using a DateTime class and you're done.

But dont' let reality get in the way of your windows bashing.

Re:idiocy? Incompetence?

[clone53421]

LOL, true.

Every number that GP types is written in a form of BCD... the subset of ASCII from 0x30 to 0x39.

Clever programs can in fact make use of this, e.g. this avoids the overhead of sscanf:

for (num = i = 0; i < l; i ++) num += (c[i] - '0') * 10^(l - i - 1);

Re:idiocy? Incompetence?

[Anonymous Coward]

I'm far more worried about the 2038 Unix overflow bug, which is a much harder bug to try and root out of systems. We have 18 years to fix that bug...

Lessee, 2038-2010 = 28 years to fix it, not 18. Most of the programmers who will be working this bug haven't been born yet. But you know what contract programmers say: Complacency is the mother of all overtime.

Heh, captcha on this post is 'pitied'.

Re:idiocy? Incompetence?

[Bigjeff5]

This is precisely why Windows no longer even fits on a DVD disc any more, and they are moving on to Blu-ray discs for distribution.

Says someone who has no clue what their talking about.

Windows OS code is not bloated because of inefficient libraries, it is bloated because, with the exception of Vista, MS bends over backwards to include hacks for legacy software. Essentially they make sure people whose code relied on some bug or quirk in a previous version of Windows still works in the next version of windows, even though the bug itself was fixed.

One example was SimCity 2000 back in the Windows 95 days. Microsoft actually put in a SC2000 specific hack just so that program would work on the next version of Windows, because they had relied on some odd behavior of Windows at the time, and there was no way to update all the copies of SC2000.

They do that kind of thing for thousands of companies with each new version of Windows, just to maintain compatibility.

Combine that with all of the new features each new upgrade brings, and you have your size increase right there. And I predict the next one will be even larger, for these very reasons. ;)

Re:idiocy? Incompetence?

[clone53421]

Why not use integer cents? or integer fractions of cents, if you need still more precision?

A DWORD would store amounts up to $42,949,672.95, or half that if you need signed numbers. A signed QWORD would go all the way up to $92,233,720,368,547,758.07... over 700,000 times the United States’ estimated national debt in 2009.

Re:idiocy? Incompetence?

[shentino]

To be quite serious, if we as a society actually live long enough to make it to 10000, and in the 8000 years until then have STILL not gotten our act together in the programming arena, then we deserve whatever crap Y10K throws our way.

Particularly after the big scare from Y2K.

Sadly, I'm not that optimistic human civ will last long enough for it to be a problem.

Re:idiocy? Incompetence?

[shentino]

Indeed.

GP should have called the contractor out on their bullshit and told them to fix the code before paying them, if the mistake was caught in time.

If most contractors are used to getting away with ripping their customers off, then perhaps getting an honest one that will survive your scrutiny will be expensive.

Re:idiocy? Incompetence?

[Bigjeff5]

The proper quote is by Robert Hanlon:

"Never attribute to malice that which is adequately explained by stupidity."

Goethe has a more long-winded version, which I like:

"Minsunderstandings and neglect occasion more mischief in the world than even malice and wickedness. At all events, the two latter are of less frequent occurrence."

Re:idiocy? Incompetence?

[hydroponx]

<quote><p>Incompetence.  Thankfully it's limited to cards made by one company.  Not so thankfully, that company supplies 40% of all debit cards in Germany.  (Insert sideswipe about monoculture here.) Finally and funnily, that company is French.</p><p>Google translation of the news here: http://translate.google.co.uk/translate?u=http%3A%2F%2Fwww.spiegel.de%2Fwirtschaft%2Funternehmen%2F0%2C1518%2C670400%2C00.html&amp;sl=de&amp;tl=en&amp;hl=&amp;ie=UTF-8</p></quote>

SURRENDER your code !

*ducks*

Re:idiocy? Incompetence?

[Archangel Michael]

We have 18 years to fix that bug

We have 28 MORE (38-10=28) years to fix it. However, we won't begin to start looking at the problem's scope until 2030 or even 2035.

That is the way of things, because it will cost less to fix the problem at that time, than it is to fix it right now. At that time, there will be a lot less of the legacy systems that have the bug, than there is right now. And fixing a problem for systems that won't even exist in 28 years from now, is wasted capital.

Re:idiocy? Incompetence?

[Bigjeff5]

Most of the current crop of problems are caused by programmers not recognizing Binary Coded Decimal numbers, probably when fixing the Y2k bug itself.

See, 0-9 look identical in Binary and BCD. However, what looks like 10 in BCD is 16 and Binary, so if you were dealing with BCD digits and thought they were plain Binary, then when the clock strikes 2010, the clock suddenly jumps to 2016. Thus, the 2010 bug.

This was a simple mistake, and an easy one to make given the circumstances. Now, all of the other problems caused by 2010 tend to be caused by pure, unadulterated stupidity on someone's part (not necessarily the programmer's, but could be).

Re:idiocy? Incompetence?

[Richy_T]

That's not really BCD (or at least not the form being discussed). For BCD, 0x68 represents 68 decimal. And 0x10 represents 10 decimal but might be read as 16 decimal which is how this discussion relates to the thread.

Re:idiocy? Incompetence?

[GameboyRMH]

IPv6 would allow over 1000 IP addresses per person on earth. There's nothing short-sighted about that. In fact it cleverly addresses the main weakness of IPv4 by allowing enough extra addresses for megacorps to buy big fat chunks of the address space without leaving the rest of the world short on addresses after just a few decades.

Re:idiocy? Incompetence?

[thePowerOfGrayskull]

he worst part of the whole thing is that we have to go back to the contractor to fix the problem which is going to cost us $$$ beyond the lost revenue of downtime.

It's unfortunate that the bar of quality is so low in this industry.

I warrant my own work against defects I caused, though I do require specific proof that it was my fault and not a requirements issue, etc-- if it is I will fix it at no charge. The scenario you describe unacceptable, yet I know it is essentially industry norm.

Re:idiocy? Incompetence?

[GameboyRMH]

You're thinking of when it hit 1234567890, on Valentine's Day 2009...as if to mock us...

Re:idiocy? Incompetence?

[clone53421]

Not the form being discussed, no, but a form of BCD nonetheless.

http://en.wikipedia.org/wiki/Binary-coded_decimal#Basics:

Thus, the BCD encoding for the number 127 would be:

  0001 0010 0111

Since most computers store data in eight-bit bytes, there are two common ways of storing four-bit BCD digits in those bytes:

• each digit is stored in one nibble of a byte, with the other nibble being set to all zeros, all ones (as in the EBCDIC code), or to 0011 (as in the ASCII code)
• two digits are stored in each byte.

Note that the 1st of those two ways is commonly referred to as “unpacked” and the 2nd way is commonly referred to as “packed” (the later section on “packed BCD” discusses a specific form of packed signed BCD for some reason, without acknowledging the normal unsigned packed BCD that is also called “packed BCD”).

Re:idiocy? Incompetence?

[clone53421]

...and there’s a 3rd way to store packed BCD even tighter, storing 3 digits in 10 bits (97.7% as efficient as binary, vs. 39.1% for normal packed BCD and 3.9% for unpacked BCD).

This, however, makes the digit triples not fall on byte boundaries.

Re:idiocy? Incompetence?

[cstdenis]

2038 bug is easy to fix. Just upgrade date to 64bit int.

This means all that needs to be done for date calculations is a recompile.

The only hard part will be comverting any on disk 32bit values to 64bit.

Re:idiocy? Incompetence?

[noidentity]

2009 in BCD is 0x20 0x09. Interpreted as binary, that's 8201. Or you're saying that they idiotically AGAIN omitted the century count, shortening it to two digits again? That's what I'd call careless.

Re:idiocy? Incompetence?

[Anonymous Coward]

Who is paying for this ??? It is costing companies lost of money to repair something that should not be. Microsoft should be sued for this incompetency.

Re:idiocy? Incompetence?

[melmut]

Indeed, it seems it's been standardized by RFC 4180, from Oct. 2005. From a quick reading, I see that they should be comma-separated. Excel encodes csv-files with a semicolumn as field-separator for a french locale (a comma being the decimal separator in this locale). So, if I read the rfc correctly, Excel breaks the standard... However, the standards is far younger than this Excel 'feature'. Anyway, I don't see how they should do it, other than using english/american conventions.

Re:idiocy? Incompetence?

[maxume]

That RFC even mentions that it is not a standard, simply documentation of stuff that exists in the wild.

Re:idiocy? Incompetence?

[Xeno man]

I know full well what I was taught and what I was not taught. How many test questions started with the phrase "In your own words..." The blanket rule was you do everything yourself to learn from it. Things I was not taught were things like Fair Use or the real legalities of copyright or plagiarism because frankly I don't think the teachers understood them either.

Re:idiocy? Incompetence?

[geminidomino]

Most of the programmers who will be working this bug haven't been born yet.

Look on the bright side. That means the guy who thinks 38-10 = 18 won't be one of them. ;)

(To GP: Just messin')

Re:idiocy? Incompetence?

[clone53421]

Or you're saying that they idiotically AGAIN omitted the century count, shortening it to two digits again?

Yes, and it’s only a problem if you want to reliably date stuff within a timespan of more than 100 years, if it’s done correctly. Short term storage doesn’t need to be permanent.

The problem occurs when you want a datestamp to always be the same... no reuse. If you store “01.01.09” in a database, you probably want it to always mean 01 January 1999. Well, what do you do after 31.12.99? You have no way to represent the date, because “01.01.00” means 01 January 1900. Your software isn’t designed to assume that “01.01.00” means 01 January 2000 if the current date is already beyond that. (Obviously the current date must always have a full, accurate year if it’s to be used to infer the meaning of shorter dates.)

The solution to this is to pivot on a moving date. If you pivot on the last 2 digits of the current year, you’ll always be able to represent dates within the past century. (To represent dates in the future as well, pivot on a future date.) The lifespan of any date so represented will be 100 years; after that, the date will be no longer representable in your date format.

So according to this method of representing past events, currently anything dated beyond ’10 is obviously from 19xx. If you have something that’s dated ’05, you don’t know for sure that it wasn’t from 1905, but if you can safely assume it’s 2005, this limitation doesn’t negatively impact you.

You just have to be positively certain that a 100-year window is large enough for whatever you’re storing in that format. Anything outside that 100-year window will have to be stored in a different format if you want to preserve its date. If you want a backup of the messages with better longevity, store them in an auxiliary format with better longevity. E.g. print them out on a dated copy and you’ll always be able to infer the century from the date on the printout.

Since an SMS message has a lifespan of hours or days at the most, they really could have likely used one digit for the date without causing problems.

Re:idiocy? Incompetence?

[Anonymous Coward]

So they are working on IPv7 for when I have a few million individually addressable nanobots floating in my bloodstream?

Re:idiocy? Incompetence?

[master_p]

Did it ever occur to you that the contractor may did it on purpose? so as that there is more work to do in the future...

Re:idiocy? Incompetence?

[Darinbob]

Deadlines. Boss wants the feature done, because the company wants profits now. They don't care if there's a major problem several years down the road (they'll probably have changed jobs by then), just that the product isn't delayed by another day. No one gets a bonus or pat on the back for fixing a problem that may happen 9 years later.

Short-term thinking is endemic in business. Collect the revenue now, and spend it before the customers wise up.

Re:idiocy? Incompetence?

[snowgirl]

Not an issue. We'll hit the Mayan calendar 2012 bug first.

Stupid Mayan computers not being able to handle a 14th B'ak'tun... why did we have to program the universe in Mayan again?

Re:idiocy? Incompetence?

[Darinbob]

What is broken in this barcode story is that someone found the error and also found the code that caused the error, but was unable for some reason to fix the code without getting the original contractor back.

It's dangerous hiring a contractor if you don't have your own employees who are capable of cleaning up the mess; or you don't collect all the necessary knowledge or tools to clean up the mess; or you don't review the work before dismissing the contractor to find out if it was a mess or not.

Re:idiocy? Incompetence?

[petermgreen]

Most of the programmers who will be working this bug haven't been born yet
On what do you base this assertion?

Lets assume that a programmers career runs from about 21 to 65 , that work on the 2038 bug runs from 2033 to 2038 and that people at any stage in thier carrer are equally likely to be working on the bug (personally I suspect it will mostly be older programmers).

that would put the programemrs working on the bug as being born between 1968 and 2017 (there may be some off by one errors in this aritmetic, they shouldn't affect the point significantly). In other words most of them have already been born.

I suspect when the 2038 bug rolls around many of us slashdotters will be the old guys who can still program in C!

Re:idiocy? Incompetence?

[snowgirl]

WinXP allows users to set date-separators and the like in a way that makes unambiguous date/time parsing impossible.

That's a microsoft thing.
Similarly, a .xls file created with a non-english excel (we often receive such files from clients who use excel in french) uses commas as the float separator and is unreadable in another version of excel.

There are tons of similar default behaviour of microsoft softwares that makes you want to kill people as soon as you begin working internationally.

While I was working for Microsoft, there was a webpage that handled various things about your paycheck, like how much to contribute to your 401(k), etc. Well, using the German client, I almost always had the German locale on my computer, and any time I told it that I wanted to save "8,00%" of my paycheck, it was all "ZOMG!!! YOU CAN'T SAVE 8000% OF YOUR PAYCHECK!!!"

There were a lot of annoying bugs in their webpages all over the place from a blanket assumption that the period and comma will be used the same as the American locale, but at the same time they apply localization upon the number.

I just wonder who did Microsoft hire that was retarded enough to localize the output but not the input? Seriously, if you can load the page, don't change anything, and hit submit, it should work regardless of locale.

I filed bugs, but if you knew how many bugs are currently active and open against various things, then you'd understand why it never got fixed.

Re:idiocy? Incompetence?

[Firehed]

Actually, some early problems would have been discovered two years ago (think: 30-year loans). In all likelihood, there are plenty of bugs out there going unnoticed because some database table is silently capping the value at the signed int limit rather than throwing some sort of overflow error. Come 2038, there may be plenty of people who get a bill for an unexpected balloon payment in the tens or hundreds of thousands of dollars. Or on the flip side, bills will stop being sent out and some bank ends up losing a ton of money.

Re:idiocy? Incompetence?

[petermgreen]

This means all that needs to be done for date calculations is a recompile.
ROFLMAO

IF the programmers have been good and actually used time_t rather than just int* AND either they haven't used it across interfaces that need to remain binary compatible AND they haven't stored it in any files then it may be possible to fix it with some clever hacks in the standard library and headers followed by a recompile with a special flag to indicate that 64 bit versions of the time functions and a 64-bit time_t should be used.

Back in the real world I expect a lot of code will need cleaning up to deal with the above issues and some libraries will either need thier major version buping (indicating a backwards compatibilty break) or to introduce a dual version system as mentioned above for the standard libraries. Anywhere the numbers are conversted to/from a byte sequence (the disk files you mentioned but also things like network protocols) will also need attention (and for shared disk files it may be nessacery to do a staged upgrade first adding support for reading the new format and then enabling writing in the new format).

And then there is the issue that to get the OS level fixes you may need to upgrade the major version of your OS and/or move to the 64-bit version of your OS (64-bit linux already has the y2K38 issue fixed) with the huge potential can of worms that opens (particually if the version of the OS that you are running is out of support at the time the 2038 bug becomes a big deal)

And then there is the fact that some source code will simply be completely lost.

In some cases the only reasonable fix may be forklift upgrades.

In summary I don't expect it to be much worse than Y2K but I don't expect it to be much better either.

* changing int to 64-bit would be almost certain to do more harm than good.

Re:idiocy? Incompetence?

[petermgreen]

Depending on how important the development is and just how much the "large sums" are it's either similar to the reverse engineering case or a case of stupid penny pinching.

Re:idiocy? Incompetence?

[petermgreen]

Copy and paste that in and your done
You shouldn't just copy and paste code in willy nilly anyway! that is what leads to cases like the recent "GPL code in MS software" incident.

What you should do is learn the facilities of the libraries available to you (most importantly your languages standard library) and make use of them. If they libraries you have available don't offer what you need then you need to weigh up the advantages of copying in code you didn't write (and may therefore have difficulty maintaining) vs adding a dependency vs reinventing the wheel.

Sadly as you say schools don't really teach this and even if they do people often end up picking up a new language very quickly without really ever learning it properly..

Re:idiocy? Incompetence?

[petermgreen]

How many hardware RTCs actually use unix time anyway? the last one I dealt with stored years (2 digit!), months, days, hours minuites and seconds (I think there may have been another field too for smaller time units, not sure offhand).

Besides hardware RTCs usually wrap in a sane way so you can postpone the bug or reduce it to a bug that only happens if the system is left turned off for insane lengths of time fairly easilly.

The difficult bit with the 2038 bug is dealing with things like file formats, network protocols, library binary interfaces etc.

Re:idiocy? Incompetence?

[petermgreen]

other than using english/american conventions.
That is what it should do, file formats should NOT be localisation dependent. If they want to create a new format that follows some other languages conventions that's fine but they shouldn't call it csv.

Re:idiocy? Incompetence?

[petermgreen]

or even, as of Jan 01 2010, the next
Yes there will be minor date related problems all the time as some obscure date format reaches it's limit or some programmer made a stupid assumption but I expect 2038 to be the next major one.

Then we have a few major date formats expiring close together, 2100 (yes people still use 2 digit years), then unsigned 32 bit unix (used in some linux filesystems and also likely to be used in many systems as a quick fix for the 2038 bug) in 2106 and dos in 2107 (used in zipfiles and the fat filesystem among other places) most of us probablly won't live to see those problems though (and some of them may well be eliminated by the systems that use them falling out of use).

Re:idiocy? Incompetence?

[ekhben]

3. Daylight Saving Time.

I.. it just...

No. Must not start ranting.

Re:idiocy? Incompetence?

[Anonymous Coward]

IIRC, all nanoseconds since the big bang will fit comfortably within 96 bits. If you round up to the nearest power of 2, 128 bits, that should more than suffice...that's roughly 4 billion times the largest value we think we'll ever need. And if you want to get truly crazy, you can use 256 bits and represent dates that even the doctor can't fathom.

But gigabit is just overkill.

Re:idiocy? Incompetence?

[the_enigma_1983]

Or when we colonize space, and have thousands of planets all with people and devices needing IP addresses.

Re:idiocy? Incompetence?

[darkpixel2k]

So they are working on IPv7 for when I have a few million individually addressable nanobots floating in my bloodstream?

...I think I would be pretty terrified if I were walking around with even *one* addressable nanobot in my bloodstream...

Re:idiocy? Incompetence?

[Teancum]

I expect that I will be dead by then due to natural causes, so I really don't care. I might be a very silver haired great-grandpa complaining about the stupid kids that have been roped into fixing the bug, letting people know that back in the 1970's when I first started to program that nobody thought their software would last that long.

As can be seen, even I can make an innocent mistake, but again... who is counting or caring.

Re:idiocy? Incompetence?

[mangobrain]

This is the kind of thing I'm talking about. To me it seems more sensible to just store cents and use all the available number range, than it does to limit yourself to BCD and open the door to misinterpretation of stored values.

Re:idiocy? Incompetence?

[mangobrain]

Those are reasonable examples, but I don't see common applications involving SMS datestamps being sent directly to 7-segment displays. Nor do I really class storage of arcade game high scores as a "file format" for the purposes of this discussion - they're only ever intended to be loaded back up by the same software, running on the same hardware. This is even more closed than, say, Word docs (pre-OOXML); at least putting a Word doc on disc and transferring it to a different machine falls under intended usage.

I'm thinking more of data interchange standards, be they open or proprietary.

Given the EE angle, I can now see how this stuff might have crept in, but am still not convinced it has any business being part of modern standards. As I said, I can see how it makes certain operations easier - so fine, store it in RAM and use it for those operations, but don't put it on disc/on the 'net if there's any chance someone else's software will have to interpret it at the other end.

Re:idiocy? Incompetence?

[richaemry]

Windows OS code is not bloated because of inefficient libraries, it is bloated because, with the exception of Vista, MS bends over backwards to include hacks for legacy software. Essentially they make sure people whose code relied on some bug or quirk in a previous version of Windows still works in the next version of windows, even though the bug itself was fixed.

By this logic IBM Z/OS would be the most bloated OS on the market since it runs applications from several different platforms with some applications dating back to the 1960's. Z/OS is not bloated, Windows is. The Windows bloat issue is due to lack of good administration. Even if you have great software engineers without high quality administration and project management to keep the code well edited bloat in sues. That is Linus Tovald's complaint about Intel bloating Linux. Without good project management every piece of software with more than a handful of authors gets bloated.

Re:idiocy? Incompetence?

[rdnetto]

My theory is that it was *because* of Y2K - lot's of sloppy code got implemented in the rush to patch everything.

Re:idiocy? Incompetence?

[The -e**(i*pi)]

its more like over 50 nonillion addresses per person

Re:idiocy? Incompetence?

[kestasjk]

I wasn't offended, I just didn't think it was funny

Re:idiocy? Incompetence?

[mysidia]

BCD works great, and is efficient, when you have 16 digits to encode. Every bit as efficient as other binary encodings. More efficient than ASCII or unicode.

0-9, A-F.

Or... 0-9 A, B, C, D, *, #

Packed BCD commonly used by standard record structures such as Bellcore AMA formats

There are plenty of good reasons to use BCD for storage in certain situations.

"A decade after the Y2K crisis"

[FlyingSquidStudios]

Crisis? There was a crisis? Other than one invented by scam artists and the media?

Re:"A decade after the Y2K crisis"

[thenextstevejobs]

Crisis? There was a crisis? Other than one invented by scam artists and the media?

Yes, exactly that crisis. And that was crisis enough

Us programmers always get the negative press.

Re:"A decade after the Y2K crisis"

[MrMickS]

Yes there was a crisis. If the effort that was put in, hadn't been put in a huge number of important systems would have failed in Y2K.

The UK emergency services number (999) was one that would not have worked had we not spent the time upgrading and patch the systems and software it depended on.

Sadly, because there was no disaster, because the work was done to prevent it, people think there wasn't a problem. I suppose we should have left the 999 service. People would have died and we could have pointed to it as an example of the Y2K bug. I think we'd probably have been sued for not fixing it beforehand though.

Try complacency

[Bovius]

Y2K ended up being a lot less scary than it could have been. Most of that is because we were prepared, turned a lot of systems off during the rollover, and then brought them back up under close monitoring.

The end result is that the populace, including business decision makers, hear about more date-related tech problems and think "Eh, it won't be that big of a deal. Y2K wasn't that bad, right?"

And now, an obligatory XKCD reference: http://xkcd.com/607/

These coders are morons.

[BikeHelmet]

Several years ago - might've even been last decade - I wrote a flash movie that checks the version number of the flash player and informs you if you need an update. And guess what? It still works fine.

That was Flash 4, I believe. Somehow due to my great forethought it was able to cope with Flash 10 without spazzing out.

Whenever I do dates, and am not using long (for miliseconds), I usually put the year in as int. I guess that means I should be set until 2 billion years or so?

Well, to be fair to the morons that coded this stuff - I'm coding in scripting languages on desktops with near limitless processing power. These devices that are messing up are probably 8-bit MCUs, where quite possibly 100% of the code is ASM. I suppose it's a bit harder to debug or think ahead because of that.

*sigh*

Re:These coders are morons.

[Anonymous Coward]

Your point stands, but there is such a thing as going a little too far with it. For instance, I'm doubtful there will be anything in existence in 2 billion years that will be capable of reading your code - should your code even exist. Code wisely, but use your memory wisely, too.

Re:These coders are morons.

[Arthur Grumbine]

For instance, I'm doubtful there will be anything in existence in 2 billion years that will be capable of reading your code...

That's probably what the Ancients thought when they built the Stargates. Never underestimate the need future species may have for a plot generation device.

Windows Mobile

[michaelhood]

http://news.cnet.com/8301-13860_3-10425455-56.html

this is affecting me and the other 3 guys on the planet with a Windows Mobile phone, too. :(

Re:Windows Mobile

[dunkelfalke]

Uhm, I am one of those other three guys but my phone (Touch HD, WM6.5 build 21896.5.0.82) is not affected.

Re:Windows Mobile

[confused one]

My phone (TMO Shadow WM6 build 18170.0.5.1) isn't affected either, apparently. So, that's all of us? Looks like it's only you then.

Re:Windows Mobile

[jargon82]

My WM phone doesn't appear to have an issue. That's all 4 of us!

Re:Windows Mobile

[Anonymous Coward]

Hi Michael! Monique and I were wondering what the problem was.

Re:Windows Mobile

[michaelhood]

I'm using a Touch Pro 2 on Sprint, 100% stock ROM etc.

MMX Technology

[hound3000]

Geez! Intel introduced MMX Technology to take care of this problem in 1996! Get with the times!

We got hit by Y2.01k

[LiquidHAL]

January 1st our 15 year old security badge system started marking all badges as invalid. Couldn't fix it until we rolled back the system date.

Re:We got hit by Y2.01k

[Culture20]

January 1st our 15 year old security badge system started marking all badges as invalid. Couldn't fix it until we rolled back the system date.

That's strange. If 10 is misrepresented as 0x10, you'd think that 0x95 would be even worse. Did it not start working until 2000?

Re:We got hit by Y2.01k

[clone53421]

It was probably a 2-digit year that was designed so the first two digits rolled over when the last two digits hit the year 10. If the year is <10, 2000 + year. If the year is >10, 1900 + year.

It’s a quick and dirty fix of the Y2K problem that merely pushes it off another 10 years.

Re:We got hit by Y2.01k

[snowgirl]

It was probably a 2-digit year that was designed so the first two digits rolled over when the last two digits hit the year 10. If the year is <10, 2000 + year. If the year is >10, 1900 + year.

It’s a quick and dirty fix of the Y2K problem that merely pushes it off another 10 years.

Easy, just move it to if $year < 20!

Or for even more fun, set if for if $year < 41, and then watch people be all confused in the year 2042, because they have no idea why someone would choose such an unusual number for your century break point. :)

Re:We got hit by Y2.01k

[clone53421]

Really the ideal way to fix the Y2K problem, in most cases, would be to break on a dynamic year, i.e. (current_year + n) where n is the number of years into the future you expect to be needing to use dates from. This keeps your window moving and you never hit a break-point. You can’t keep data around longer than (100 - n) years, unless you also store a full date with it so you can calculate what the 2-digit dates represented. In most cases, though, you don’t need to keep stuff that long anyway.

Re:We got hit by Y2.01k

[snowgirl]

Really the ideal way to fix the Y2K problem, in most cases, would be to break on a dynamic year, i.e. (current_year + n) where n is the number of years into the future you expect to be needing to use dates from. This keeps your window moving and you never hit a break-point. You can’t keep data around longer than (100 - n) years, unless you also store a full date with it so you can calculate what the 2-digit dates represented. In most cases, though, you don’t need to keep stuff that long anyway.

The joke was not to really solve the problem, but rather two more humorous examples of the "just push it off 10 years" idiocy are presented in order to evoke humor.

The first only takes the problem of pushing it back ten years, and pushes it back ten years.

The second presents a non-round number to push the problem back by, and thus when 2042 arrives, everyone is confused why there is a Y2K bug presenting itself, because it's not on a round year. ... the number 42 was chosen as "the answer to life, the universe, and everything" in order to increase the likelihood of the joke being caught, rather than presumed to be real.

Or to paraphrase for summary.... "whoosh"

Re:We got hit by Y2.01k

[clone53421]

Or to paraphrase for summary.... "whoosh"

Yes... I know...

the eternal curse of the software developer

[Tumbleweed]

Programmer: "I want to take some time to refactor some of the older code."

MBA: "What's the ROI on that?"

Programmer: "DIAF."

Re:the eternal curse of the software developer

[kestasjk]

MBA: "And why do you need to do this refactoring?" Programmer: "I didn't expect my code to be in use (in these ATMs) for more than a few years. Numbers don't come cheap in computers you know"

Re:the eternal curse of the software developer

[Errol backfiring]

Can you explain the TLAs and ETLAs used? Maybe we can all understand what you are trying to say...

Re:the eternal curse of the software developer

[Anonymous Coward]

Can you explain the TLAs and ETLAs used? Maybe we can all understand what you are trying to say...

DIAF -> Die in a Fire
ROI -> Return on Investment

also, http://justfuckinggoogleit.com/

Re:the eternal curse of the software developer

[bwintx]

"DIAF" = "Die in a fire." If you need help with "MBA" and "ROI" -- well, you're probably saner than most of us here. :-)

Re:the eternal curse of the software developer

[Anonymous Coward]

second and first result on google, respectively.

does the wii has a minor 2010 issue?

[Anonymous Coward]

Playing wii new years eve. The thing hard crashed exactly as the year changed (it was in the menu not a game). After a reboot it was fine.

Re:does the wii has a minor 2010 issue?

[kestasjk]

At least the situation is too embarrassing to file a bug report

Re:does the wii has a minor 2010 issue?

[Vitani]

I too was playing on my Wii at midnight (Frisbee Golf!) but it's survived the year change, must be a bug on the Wii Menu!

Re:does the wii has a minor 2010 issue?

[larry bagina]

I was fucking a trollop on new years eve. She vomited exactly as the year changed. She wasn't MD 20 20 compliant.

Endpoint Protection

[juventasone]

Is "network-access control software" the new term for a firewall? Even so, Symantec Endpoint Protection is primarily an anti-virus, with the usual additional features, as well as some enterprise ones like "device control" for pesky flash drives. It was an all-new product back in 2006. Although the problem only interferes with the reporting, and not the function of its management console, I think it's quite embarrassing.

Re:Endpoint Protection

[drinkypoo]

All I know about Symantec and updates is that Norton Antivirus Corporate Edition had a bug where it would occasionally refuse to pull updates unless you were running their magical server product. You fixed it by uninstalling and reinstalling. This bug persisted at least from Norton 7 to Symantec AV 9.

Spamassassin

[j_sp_r]

Spamassassin in Kerio Mailserver has a bug that flags all messages dated 2010 as spam. I think it affects the normal spamassassin as well.

Re:Spamassassin

[Athanasius]

That's been all over the tech. news, yes. To be fair to Spamassassin, at least it uses a score, not purely 'flag' system. None of my personal email was affected as my threshold is above that of the "too far in the future" rule.

I do wonder why patches didn't get pushed out sooner, apparently it was fixed in the SA CVS system months ago.

Furthermore I wonder if anyone's tried to come up with a rule that is "today's year plus X" rather than matching a fixed range of years (it was 2010-2019, now it's 2020-2029), as things now are we'll hit the same problem again in 10 years time if no-one remembers to bump things before that rollover.

Re:Spamassassin

[darkmeridian]

There was a flaw in the Spamassassin rules that set 2010 as a date so far off that it has to be spam. There is a patch that says 2020 is that date, not 2010. Hopefully, someone will update the rules regarding 2020 before 2020 rolls around.

Re:Spamassassin

[Anonymous Coward]

What do you want? 2010 is grossly in the future. And I'm looking forward to my 19th birthday.

Re:Spamassassin

[Anonymous Coward]

That's because there's a rule in 72_active.cf that would check if e-mail was too far in the future.. That rule started with mail date 2010 or beyond, which was fine a few years ago, but the rules has to be edited to go to 2020 now, or just score it as 0.

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006] is the problem. Change it to /20[2-9]..... Or just change it's score to 0 to bypass it entirely.

Re:Spamassassin

[Anonymous Coward]

You must be running it on Windows. KMS 6.7 on Fedora Core has no such issue.

Mod funny

[EvanED]

I don't have points at the moment, but well done.

Check your dates

[madsenj37]

Midnight, December 31, 2010 has not happened yet. You must mean Midnight January 1, 2010.

My ThinkPad had some trouble too.

[TxRv]

When I booted it the next day the hardware clock thought it was 1987, and it couldn't mount the filesystem. In the console I eventually got to I found all my stuff was fine and the filesystem was mounted, but the firmwarewasn't seeing it. I manually the hardware clock and it hasn't had any problems since.

I was in the field when it happened, so the whole thing scared the shit out of me. I shudder thinking of what will happen come 03:14:07 UTC on Tuesday, 19 January 2038.

Re:My ThinkPad had some trouble too.

[B2382F29]

[..] I manually the hardware clock [..]

Did you accidentally the whole clock?

Re:My ThinkPad had some trouble too.

[Anonymous Coward]

No. On purpose

Re:My ThinkPad had some trouble too.

[Anonymous Coward]

I shudder thinking of what will happen come 03:14:07 UTC on Tuesday, 19 January 2038.

Free pie gives you the shakes too?

Re:My ThinkPad had some trouble too.

[Chris Mattern]

I'd be more tempted to blame that on a failing CMOS battery than 2010.

Re:My ThinkPad had some trouble too.

[TxRv]

Definitely not! I learned that lesson after the time I accidentally my whole filesystem!

Re:My ThinkPad had some trouble too.

[TxRv]

Any idea how would I go about figuring out if that's what it is?

Re:My ThinkPad had some trouble too.

[Chris Mattern]

If it's the battery, you'd expect to see this behavior every time you power up the computer, but it's possible the problem is only intermittent, in which case there's no easy way to determine. If you see it during a restart where the computer was never actually powered down, then it's probably not the battery. I'd give serious thought to just replacing the battery on general principles, since losing CMOS configuration this way is a battery problem the vast majority of times. CMOS batteries aren't very expensive (generally about $12, although it can vary considerably depending on the exact model). You'll need to determine exactly what battery your motherboard takes, as different boards use different battery models.

Re:My ThinkPad had some trouble too.

[TxRv]

The problem started up again on the next boot after Iposted that. You're right about it being the CMOSbattery. I'm looking into a replacement right now.

Thanks for the help!

Good.

[AK Marc]

I did Y2K remediation. I've seen it called a waste of resources and that because nothing happened, nothing would have happened. This is the smallest taste of what would have happened if Y2K weren't addressed. Only we would have had airliners fall from the sky (silly? Military jets had all navigation crash when crossing the date line, and if not for a tanker with them and that communications worked when navigation failed, they would have crashed). But with a lot of hard work, it was a non event.

Though, if anyone could tell me why my power went out at exactly midnight on that night, I'd love to know. The Preston Hollow neighborhood in Dallas did have a power failure right at midnight. And I never could figure out what happened. But all the equipment I was responsible worked flawlessly.

Re:Good.

[RAMMS EIN]

``Though, if anyone could tell me why my power went out at exactly midnight on that night, I'd love to know.''

Same here. Why would the system supplying the power be dependent on the time? For navigation systems, I can sort of see a case ... not that it would be a good idea, but I can imagine how it could work (that is, fail). But this?

Re:Good.

[drinkypoo]

(silly? Military jets had all navigation crash when crossing the date line, and if not for a tanker with them and that communications worked when navigation failed, they would have crashed).

If avionics failed, they would have crashed. But if these fucks can't land planes on basic instrumentation then they probably shouldn't be piloting military hardware.

Re:Good.

[larry bagina]

I don't know if it's fact or urban legend, but my understanding is that some stealth planes can't be flown without computer assistance since being stealthy is more important than being able to fly them.

Re:Good.

[pjt33]

Power requirements fluctuate. You get spikes caused by things like lots of people cooking breakfast at the same time (a 2kW electric kettle by itself draws more power than most of the other stuff in the house put together; if your country has a lot of electric showers then lots of people turning the shower on at the same time would be even worse); lots of people making drinks (those kettles again) during the ad breaks in popular TV shows; etc. Power generation needs to be ramped up in anticipation of these demands because storing electric energy is inefficient and generators don't just come online and immediately start operating at capacity on the flick of a switch.

Re:Good.

[sgtrock]

Well, much of the international dateline is over the Pacific Ocean where land masses tend to be really small, few, and very far between. Depending upon where the jets were when the incident happened, I can see where a navigational systems crash may have meant attempting a water landing in an aircraft not exactly designed for it.

Amelia Earhart isn't the only one to end up in the drink, after all.

Re:Good.

[zaffir]

That sounds like a steaming pile of bullshit.

However, some planes cannot be flown without computer assistance. Anything fly-by-wire (such as the F16) is like that; the pilot has no mechanical link to the avionics, only digital inputs from the joystick, throttle, etc.

Re:Good.

[Anonymous Coward]

It's not horseshit, but it also isn't because of stealth. Modern fighters are inherently unstable aircraft. Without the avionics, even if they did have mechanical linkages no human would be able to fly them. They do this on purpose because they're unstable in ways that increase maneuverability, which is extremely important for a fighter to survive a dogfight.

That said, the crash the OP was talking about was in the navigation software, not in the avionics. There's a reason the avionics software is held to a much higher standard.

Re:Good.

[maxume]

I'm pretty sure this is true for at least the F-117.

Re:Good.

[thePowerOfGrayskull]

Indeed, it always gets under my skin to hear it called "a lot of noise about nothing" or oversimplified to the point of "computers would think your newborn was born in 1901!"

I also worked on Y2K remediation -- and the issues we found and fixed were far from trivial. Had the effort not been applied, it would have been as catastrophic as predicted. That it went as smoothly and quietly as it is the result of uncountable hours of analysis, development, and testing.

Weird

[EvilAlphonso]

I live in Germany and didn't notice a single problem with our cards. Granted we replaced ours a couple months ago due to another issue.

Re:Weird

[Colin Smith]

I live in Germany and on monday stood in line at the local bank when it opened behind about a dozen people who had their cards eaten by the ATM.
 

Re:Weird

[Anonymous Coward]

youd think the first one or two would warn the others not to put it in the atm..

Re:Weird

[StuartHankins]

Chalk it up to schadenfreude

Re:Weird

[petermgreen]

Afaict it's quite common for ATMs to refuse to return cards if they think something is wrong with them or think they are stolen.

I could easilly see it taking three or four people before they realised it was a more general problem.

And maybe some of these people had the problem at different ATMs (afaict most places have more ATM locations then bank branches) and/or different times (I dnunno if banks in germany open at the weekend or not, I'm pretty sure most of them don't here in the UK).

All in all for 12 people to be at a bank branch with the problem would not really require stupidity on the customers part.

It's Y2K01

[El_Muerte_TDS]

I think the proper way to denote year 2010 is Y2K01, just like 14K4 was used for 14400.
Of course writing Y2K01 or Y2.01K is more difficult than Y2010, so why bother using that arcane notation.

Re:It's Y2K01

[Anonymous Coward]

I think the proper way to denote year 2010 is Y2K01, just like 14K4 was used for 14400.
Of course writing Y2K01 or Y2.01K is more difficult than Y2010, so why bother using that arcane notation.

Nope, I think it's actually Y2.01k
A lower cased k == 10^3 (as in kB, kg, km, etc...)

(an upper case K would denote a temperature measured in Kelvin)

Re:It's Y2K01

[omglolbah]

In electronics and many engineering situations decimal points are not used. Usually because they can be lost in copying due to small imperfections etc.

So 1.2kOhm would be written as 1k2 ohm.
10.2 ohm would be 10r2. You can see this in a lot of older schematics. I think some confuse this standard where you would write 2010 as 2k010, the last zero can of course be dropped.

Not sure which one I would prefer, just throwing in the information as it seems to be the 'solution' of sorts to the confusion?

Re:It's Y2K01

[Anonymous Coward]

Yeah, someone made the same comment here. Some douche no doubt jacking off to hentai completely missed the boat and argued about EEs and context. Any time that you bring it up, these morons will shoot it down saying that you should get with the times and understand their terms (even if they deprecate solid, accepted ones widely in use). These are the same morons who actually consider "blogosphere" a word.

Captcha: winers

Re:It's Y2K01

[vettemph]

My credit card ends in the digits 9090. I pronouce it "ninety ninety".
My wife says it is "nine oh nine oh", (...as in the Mork greeting) and gives the hand guesture.

Re:It's Y2K01

[snowgirl]

I think the proper way to denote year 2010 is Y2K01, just like 14K4 was used for 14400.
Of course writing Y2K01 or Y2.01K is more difficult than Y2010, so why bother using that arcane notation.

Because Y2.01K is funnier.

So Y2K...

[Anonymous Coward]

...was simply a rounding error?

Do people never learn?

[Bert64]

With all the hype of y2k, you'd think that would be enough to push people into action and learn how to handle dates correctly... Instead, some people "fixed" y2k problems with another series of short sighted dirty hacks that are now starting to break again after only 10 years.

What's the main bug?

[Anonymous Coward]

"This is no coincidence, according to comments on sites discussing the issue. 2010 represented as a binary coded decimal is being interpreted by other devices as hexadecimal, which translates 2010 to 2016"

Last time I checked 2010 in binary was 11111011010 and 2016 in hex was 0x7E0.

Am I missing something?

Re:What's the main bug?

[Anonymous Coward]

You don't think people were actually smart enough to stop using two digits after Y2K, are you?

0x10=16

Re:What's the main bug?

[Skapare]

An apparent requirement was to squeeze the year into a single byte. They just did it very badly by choosing BCD format for the last 2 digits of the year, and assuming every new CS grad would know what that means, and would understand by examining the existing data field where 0x03 was present for 2003 and 0x04 was present for 2004 that it must be in BCD. Since BCD and plain binary share the same values for 2000 through 2009, it fully depended on the programmer reading AND UNDERSTANDING the documentation to get it right ... if the documentation even reliably pointed this out.

We need to get away from BCD encodings. It was convenient for hardware level protocols because they allowed displays of decimal digits without further conversion. Do we do that anymore? Unlikely. We have software or firmware, and that can do decimal conversions just fine. All NEW communications protocols should from this day forward use only one of a binary format with a documented resolution and sufficient bits to last until at least the year 2200, or characters with the date in a format with year first, month next, and day of month after that, or a plain decimal count of days since the epoch. Where an epoch is needed, it must be clearly documented.

Re:What's the main bug?

[clone53421]

The 2-digit year “09” (2009) is 0000 1001 in either binary or BCD. So when you reverse-engineer the BCD date field, you assume it’s a binary number when in fact it’s BCD (and you should have looked it up, instead of assuming this).

Then you get to year “10” (2010), which is 0001 0000 in BCD, not 0000 1010 as you expected. 0001 0000 is binary for decimal 16. Welcome to year 2016.

Y2.01K?

[Anonymous Coward]

How about MMX? I like confusing other people by reusing acronyms. Even better if I could walk around with a slot 1 Pentium and wave it in front of IT staff while mentioning it...

Re:Y2.01K?

[jimicus]

How about MMX? I like confusing other people by reusing acronyms. Even better if I could walk around with a slot 1 Pentium and wave it in front of IT staff while mentioning it...

You'd certainly confuse people doing that. Early Pentium IIs used a slot, Pentiums used sockets.

Re:Y2.01K?

[petermgreen]

At least you'd be in good company

What the hell?

[Arancaytar]

Is this some kind of job security feature?

I mean, what idiot programs a number field to be ambiguously hexadecimal or decimal? Of course you'll be screwed as soon as you leave the single digits.

Re:What the hell?

[Anonymous Coward]

Is this some kind of job security feature?

Yes.

Hit my Garmin too.

[Ranzear]

Last year I had my Garmin GPS's traffic module enabled for a year 'subscription', which is effectively a code that tells the unit 'enable yourseilf until xxx date'. It expired a few months ago. Now, come Jan 1st, 2010, its magically back on without any reactivation. Not sure if I want to tell them straight away, I, and many others I'm sure, just saved $70 by their programming error.

2038

[taniwha]

2038 bugs are already here - I ran foul of OpenSSL failing valid crypto certs with end dates past then last year (now fixed)

Re:2038

[Anonymous Coward]

Yes indeed. For example, 30-year mortgages starting in 2010 end in 2040. Somewhere there has to exist software that can deal with this.

Another bug

[lagfest]

All the parking ticket dispensers in copenhagen also bugged out. http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.berlingske.dk%2Fkoebenhavn%2Fparkeringsautomater-afviser-dankort&sl=da&tl=en

Quick fixes from 1999

[s7uar7]

I'd be willing to bet that some of this has been caused by, "just change it so that if the year is 10 then assume it's 20??, we'll fix it properly before then".

Re:Quick fixes from 1999

[s7uar7]

the year is 10

Less than 10, damn /.'s filtering.

Im pissed!

[chucklebutte]

With all the shit we swallowed when they shoveled that Y2K shit down our throats and not a peep about this? No mass fucking hysteria? Seriously fuck you assholes that run the world!

CSV in Excel is the same with regional settings

[Anonymous Coward]

Unfortunately csv files from different regions won't work in excel either, due to the fact that excel uses the separator from your regional settings rather than always using commas like you are supposed to with a COMMA separated value

Y2.01K?

[agw]

Y2.01K? That's surely a plot of the hard disk industry.
Everybody knows that Y2010 are only Y1.963K.

Perpetual calendar anyone ?

[slb]

Incredible that we're still keeping this outdated Gregorian Calendar instead of a Perpetual Calendar that would solve all these idiotic fiddling with complicated date mechanisms.

Re:Perpetual calendar anyone ?

[Jesus_666]

Except that the World Calendar still doesn't do anything about this year having a different number form last year. In fact, it makes computational handling of dates more complex as we suddenly have one or two days a year that don't have a number.

Re:Perpetual calendar anyone ?

[Chris Mattern]

Frankly, having the machine handle dates in any fashion other than in POSIX time format or similar is nutso. Convert it when you have to show it to a user to whatever is convenient for that user, but internal format should be be something that encourages simple, bug-free code.

Me Too

[cyclomedia]

We also had an issue where something stopped working on 2010-01-01 because it was so far off in the future that it wouldnt matter. When was this code written? 2006! On the other hand the dev responsible no longer works here so the Make-It-Someone-Else's-Problem method worked perfectly...

stupidity

[Anonymous Coward]

This is not about a 2010 problem. This is about incredible stupid programmers / hardware designers.

Work Ethic Thread

[EmagGeek]

Should this story be merged with the story about the lack of work ethic in the software industry?

Re:Work Ethic Thread

[ServerIrv]

I'm not trying to excuse these bugs, but I remember how crazy it was for programmers to simply add hacks to make Y2K work. Once Y2K rolled past without incident, the MBA's couldn't be bothered with another doomsday since they had just spent mega dollars fixing this one. When there isn't funding or approval, the code doesn't get refactored. If there isn't enough space in your DB, add it before it fills up instead of short-shrifting on storage space for properly formatted dates. Also, another problem I've seen is attributes (explicitly dates) being stored in ID fields. If you really want that to work, combine them but don't shorted them. end rant.

I can certainly vouch for this.

[gorzek]

I work for a software company that's been in business since 1978. The product I work on is a real-time pharmacy benefit adjudication system, so it has to be up 24/7. They had one guy do Y2K fixes back in '99, and he retired last summer without telling anyone his Y2K "solution" was to just add 100 to any data containing a year. With the way this software works, that was fine--until 2010. Something tells me the timing of his retirement wasn't coincidental! It wasn't hard to fix, but some people took really absurd shortcuts fixing Y2K bugs, when there are plenty of ways to do it that are just as simple and won't break after 10 years.

Re:I can certainly vouch for this.

[petermgreen]

there are plenty of ways to do it that are just as simple
I'm not sure there are

Consider you have a system that stored it's data in old fasioned flat files with say a 2 digit BCD year, I see four possible fixes each with it's issues

1: move to a psuedo-bcd format that can represent numbers up to 150, existing data all remains valid and the system is good for 50 years BUT you will have to write your own arithmetic/conversion functions for psuedo-BSD and hunt down everywhere BCD arithmetic or conversion is used in the code and change it.
2: implement a system that redefines the date field such that numbers below a certain threshold are considered to be in 20xx, the problem then becomes chosing that threshold, too large and you risk breaking historical data, too small and you get breakage again after a relatively short period.
3: implement the above but with a sliding window based on the current date, at first this seems like a good idea but it could cause a lot of confusion when say 90 year old (if your window is 90 years in the past and 10 years in the future) data starts being interpreted as being in the future. Possibly this could be worse than a system that breaks for new data depending on how long it takes to realise that data is being misinterpreted
4: change the file format and either convert all existing data or implement a file format version detection system

4 is the only proper long term fix but depending on details of how the data is stored is likely to be very intrusive.

any other soloutions you can think of?

How can this happen...

[Anonymous Coward]

Easier than you think. Let's start with the temporary nature of Y2K remediation work. It was the last hurrah for many in the COBOL world. If your contract expires in January or February of 2000, any defects that trigger in 2010 are (at worst) additional revenue opportunities. The people who did this work had no incentive whatsoever to make a permanent solution. Do automobile manufacturers want their cars to last forever?

Now, let's mix in a smidgen of expediency. Instead of fixing the data structures, in some cases it was easier to fool the few programs that used date arithmetic. How does it work? Choose a number to serve as a "pivot year". 20 is common, though 10 is possible as well. Anyone born in 1910 will be 90 in 2000. From this, we can assume such people are retired (if they are even alive). So the programs assume any 2-digit year pivot year are 1900 + $YEAR. The problem with the pivot year is that you eventually reach that year and something else has to be done. If you think 2010 is a problem, just wait until 2020!

Management bought into the short-term fixes, because they figured one of several things would make it OK: (1) New systems. We will be replacing everything before 10 years, so this is no problem. (2) "I will be working elsewhere", either by corporate merge/purge or job hopping... (3) Short-term thinking. If it doesn't matter to the CEO (whose idea of long-term thinking is the end of the fiscal year instead of merely end-of-quarter or end-of-month), why should it matter to me?

In the world of "weak IT", budgets are controlled by finance, and resource tracking is the name of the game. Development stops when the budget runs out. IT management often reviews the scope of work and offers a range of options, from the quick and stupid to the gold-plated permanent solution. Somehow, the budget for the project is 90% of the cost of quick and stupid, leaving IT with two major headaches: Figure out a way to cut 10% of something that was already quoted at rock-bottom, and deal with "corporate amnesia" when management discovers they didn't get the gold-plated solution because they wouldn't even properly fund the quick and stupid approach.

Another one.. NSDQ

[Anonymous Coward]

Another one.. Nasdaq is sending Administrative messages over it's feed lines that are incorrect. This:

1:15@M3T1

Should be:

10:15@M3T1

The first 2 characters being the year.

Luckily it's only administrative messages, and they only show up out of market hours.

Got hit by this one myself

[Chris Mattern]

SunPCi cards are essentially x86 PC blades designed to be plugged into a PCI slot on a Sun SPARC machine. I use a SunPCi III in the Sun Blade 1500 (SPARC desktop) I have on my desk to run software I have to run that requires Windows. This Monday, I fired it up and got told by the driver software that my system date was in the future because "I can't believe it's really" 2010 (the exact words of the error message!). Looking at the Sun forum message traffic, apparently *everybody* with a SunPCi III card is getting this. Sun's supposed to be working on a patch now. Right now the only workaround is to set your system clock back to 2009 when you fire up the SunPCi card (you can set it back to correct after it starts).

Re:Got hit by this one myself

[snowgirl]

SunPCi cards are essentially x86 PC blades designed to be plugged into a PCI slot on a Sun SPARC machine. I use a SunPCi III in the Sun Blade 1500 (SPARC desktop) I have on my desk to run software I have to run that requires Windows. This Monday, I fired it up and got told by the driver software that my system date was in the future because "I can't believe it's really" 2010 (the exact words of the error message!). Looking at the Sun forum message traffic, apparently *everybody* with a SunPCi III card is getting this. Sun's supposed to be working on a patch now. Right now the only workaround is to set your system clock back to 2009 when you fire up the SunPCi card (you can set it back to correct after it starts).

I remember that when Wing Commander 3 is installing, it will test system performance including your CD-ROM speed. Run on a modern system the test returns the error, "Your CD-ROM is reading faster than is physically possible. Please disable any disk-caching programs you are running to ensure best performance." The second sentence is a paraphrase, but the first is pretty much the exact wording.

Symantec has a minor but annoying bug

[Nimey]

SEP11 has a rather stupid bug that causes it to not update its virus-definition datestamp past 20091231. The definitions continue to be updated, but the program complains to the user that it's out of date, and so they panic and bother us until the dumbass Symantec engineers get around to fixing whatever the bug is.

I can't believe this.

[hallux.sinister]

How hard is it to use a 4 digit decimal to represent the year? Watch this: Decimal 2010. This should work until 9999 A.D., by which time, I think it's safe to say, no computer hardware or software in use now will still be in use then.

Okay, admittedly, there may be a few machines still running *NIX but... but that's really a long, long, LONG way off.
~Hal

It's the money, stupid

[Daddy-Oh]

Prior to "Y2K", I saw far too many mediocre "consultants" make more money than God by spreading FUD about the possibility that your software would 'esplode on midnight 1/1/2000. Were there systems that would be affected? Sure. Back when storage and memory cost money, the amount of space used by data was an issue that could not be ignored, and that led to decisions in system design that caused the issue. Heck, who thought that any single piece of software would still be relevant 20 years after it was written? But, so-called experts came out of the woodwork to "help" businesses through the non-crisis by charging them huge rates.

But, to have this really happen on "modern" systems seems unacceptable to me. I half expect to see another new breed of "expert" consultant who specializes in reviewing all of your code to make sure you are next-year compliant.

Of course, maybe I'm just envious that I didn't capitalize on that feeding frenzy in the first place....

--

If "external" is the opposite of "internal", what is the opposite of "increment"?

OK, OK, OK, OK. Let me say this one thing.

[WheelDweller]

The unix idea of one-second-per-integer-count sure looks good now, doesn't it? No wasting time with hex, no fiddling to learn how now+1,000,000 seconds would be....and all we have to do is enlarge the number incremented to continue the smooth operation.

Can't we all agree on any ONE thing, like this well-documented, clearly laid-out concept? Doesn't 'simple' work well over time?

I'm just saying...inventing shorter-sighted, count-only-years plans are less than this, and they don't work that long. Let's agree one this one thing and never look back to Y2K again, aye?

PS: I'm well aware of unix apps the eschew system-time and invent calendars of their own. It's also what I'm talking about.

Re:OK, OK, OK, OK. Let me say this one thing.

[clone53421]

The unix idea of one-second-per-integer-count sure looks good now, doesn't it?

Leap years, leap seconds, and what’s now + 1 year?

Better it may be in some respects, but not “simple” in all cases.

Anonymous Coward

[Anonymous Coward]

Add NetNewsWire to the list of buggy programs. Granted, I was one version behind current, but that's only because they changed the location of the updates so the automatic update function was silently failing rather than telling me a new version existed.

I had my retention set for 1000 days after a news item is removed from the RSS feed. Thaty might sound excessive, but when I flag things to go back to, I don't want to have some artifical deadline set for when I must get back to it. If there was a 'forever' option, I would have picked it. With a number of active feeds, such as /., that quickly grew to over 18000 items since I started using it in April of last year.

When midnight hit, I heard quite the churning from my computer, which was dismissed as a number of cron jobs having a party. Also, I aws more pre-occupied with my party, watching fireworks and drinking scotch. A couple hours later I sat down at my desk and noticed the unread count being displaed rather considerably lower (I don't keep up with every feed, so it was up to 4 digits, but now was down to 2 digits). I scanned over a few feeds and noticed that nothing older than a few days existed in most except those that keep items in the feed for a long time, which tend to be low activity feeds. As best I can tell, its date handling code figured that 2010/01/01 - 2009/12/31 > 1000, so it proceeded to purge ALL new items not still in an active RSS feed. Shit....

I had a backup from mid November, but that was it. This isn't something that goes under any of the normal backups, but it probably should have. Hindsight and all that. Ironically, NetNewsWire backups up its data to some extent, too bad its not useful. The feeds are stored in plists, which are loosely structured XML files for those not familiar with OS X, which means flat files of several megabytes for active feeds. Those files are NOT backed up. What is backed up is the list of feeds, something that could be recreated by parsing the first few lines of each feed 'database', but apparently that's the important part because it keeps several dozen copies of this file in the backups directory, despite it not changing between any of the copies.

I'm fairly convinced now that more thought was put into the ability to deliver ads (take it from commercial, to free to get users, then to adware to spray ads at those that are hooked and have their data trapped with no export function for anything but the list of feeds) than to any functional aspect. That, or the programmers are simply retarded. Well, guess what? I'm not locked in anymore because I have no data worth retaining. The most relevant articles are the most recent, and those are what is gone (the last 6-7 weeks). So I jumped ship, all new stuff goes elsewhere. If anyone should happen to have feeds data from /. and Ars Technica for Nov-Dec 2009, in NetNewsWire files or any other format, that would care to share it that would be greatly appreciated. This also raises questions in my head about RSS. It acts like a itemized exporter to a certain externt, but it has no ability to provide access to the stuff not judged 'current' by the feed operator. It would certainly be nice if there was some standard mechanism to pull items from sites in a logical fashion that permitted archival access. Pulling the whole page when the page is merely a grouping of smaller logical items is messy.

NetNeewsWire sucks too

[Anonymous Coward]

Add NetNewsWire to the list of buggy programs. Granted, I was one version behind current, but that's only because they changed the location of the updates so the automatic update function was silently failing rather than telling me a new version existed.

I had my retention set for 1000 days after a news item is removed from the RSS feed. That might sound excessive, but when I flag things to go back to, I don't want to have some artificial deadline set for when I must get back to it. If there was a 'forever' option, I would have picked it. With a number of active feeds, such as /., that quickly grew to over 18000 items since I started using it in April of last year.

When midnight hit, I heard quite the churning from my computer, which was dismissed as a number of cron jobs having a party. Also, I was more preoccupied with my party, watching fireworks and drinking scotch. A couple hours later I sat down at my desk and noticed the unread count being displayed rather considerably lower (I don't keep up with every feed, so it was up to 4 digits, but now was down to 2 digits). I scanned over a few feeds and noticed that nothing older than a few days existed in most except those that keep items in the feed for a long time, which tend to be low activity feeds. As best I can tell, its date handling code figured that 2010/01/01 - 2009/12/31 > 1000, so it proceeded to purge ALL new items not still in an active RSS feed. Shit....

I had a backup from mid November, but that was it. This isn't something that goes under any of the normal backups, but it probably should have. Hindsight and all that. Ironically, NetNewsWire backups up its data to some extent, too bad its not useful. The feeds are stored in plists, which are loosely structured XML files for those not familiar with OS X, which means flat files of several megabytes for active feeds. Those files are NOT backed up. What is backed up is the list of feeds, something that could be recreated by parsing the first few lines of each feed 'database', but apparently that's the important part because it keeps several dozen copies of this file in the backups directory, despite it not changing between any of the copies.

I'm fairly convinced now that more thought was put into the ability to deliver ads (take it from commercial, to free to get users, then to adware to spray ads at those that are hooked and have their data trapped with no export function for anything but the list of feeds) than to any functional aspect. That, or the programmers are simply retarded. Well, guess what? I'm not locked in anymore because I have no data worth retaining. The most relevant articles are the most recent, and those are what is gone (the last 6-7 weeks). So I jumped ship, all new stuff goes elsewhere. If anyone should happen to have feeds data from /. and Ars Technica for Nov-Dec 2009, in NetNewsWire files or any other format, that would care to share it that would be greatly appreciated. This also raises questions in my head about RSS. It acts like a itemized exporter to a certain extent, but it has no ability to provide access to the stuff not judged 'current' by the feed operator. It would certainly be nice if there was some standard mechanism to pull items from sites in a logical fashion that permitted archival access. Pulling the whole page when the page is merely a grouping of smaller logical items is messy.

(slashdot comment interface, along with much else of the site, has apparently gone straight to hell in the time I've not been using the site directly. yay anti-intuitive interfaces! buttons that don't do what they say, unlabeled form fields, hidden controls, its just like windoze now, wheee)