blog Call us nostalgic, but today’s news that the Health Industry Claims and Payments Service (HICAPS) system owned by the National Australia bank was taken down by faulty programming associated with today’s leap year date takes us back to the good old days of Year 2000 bugs. There’s a statement on the matter on the HICAPS website, but the Sydney Morning Herald probably has the best story on the issue:

Today’s extra day in February has caused the payment system used by the health industry to crash, preventing 150,000 customers from using private health care cards for medical transactions.

Delimiter had been told by an anonymous tipster that Commonwealth Bank of Australia’s ATM and EFTPOS outage (the Herald Sun has a most amusing story on the issue this morning, quoting “furious customers”) was due to a leap year bug as well, but the bank has now denied this.

Does anyone else fondly recall the frenzy of coding which was going on in the dying days of 1999, as developers all around the world frantically tried to apply patches to stop their systems going down? The global panic that was predicted? And the complete lack of any actual problems when the new year ticked over? Well, it’s good to know that weird dates still cause programmers problems. Even major Australian banks don’t appear to have that one nailed down just yet ;)

Related posts:

1. This is the year for NAB core banking overhaul
2. ANZ flags murky “20-year” technology plan
3. Elders inks seven-year outsourcing deal with HP
4. HP Touchpad to hit Australia ‘later this year’
5. vividwireless cuts prices for the new year

Tweet

1. Jazzhunt
   Posted 29/02/2012 at 6:03 pm | Permalink | Reply

   I do get a little irritated about Y2K deniers. I remember very well how many smart and dedicated people spent thosands of man hours working hard to prevent any problem when the clock ticked over, pretty much throughout the ’90′s. And when the time came and there were (almost) no problems did those smart and dedicated people get any praise for a job well done? No. Essentially everyone said “Well, if nothing happened there was no risk in the first place and you just ripped us off.”
   A good mechanic services your car to prevent unexpected problems and people understand that but when IT professionals do the equivalent they get derided as panic-merchants.
   Even now, more than a decade later, I still get annoyed on behalf of those who did a damn fine job.

   • Y2k survivor
     Posted 29/02/2012 at 6:13 pm | Permalink | Reply

     +1. No praise for avoiding disaster

     • Ben Zemm
       Posted 01/03/2012 at 12:08 am | Permalink | Reply

       Plenty of minor issues were apparent, such as 192000 or 19100 being displayed instead of 2000, so it’s not impossible that many showstopper bugs were squashed by competent people! I even saw one thing stop working on 9/9/99. I probably won’t live to be 120 and see what happens on 01/03/2100 as 2100 is not a leap year, despite 2096 and 2104 being one.

   • Yem
     Posted 01/03/2012 at 9:47 am | Permalink | Reply

     +1
     So much work went into stopping Y2K issues. Only beacuse there were only minor issues, people think it was a non issue. It was through hard work that there were no major outages. Hard to have recognition when no disaster happens because many people worked to prevent it happening.

2. Gav
   Posted 29/02/2012 at 7:50 pm | Permalink | Reply

   Dates are a real pain to code for, and very easy to stuff up. Just when you think you’ve done everything right, there’s an edge case that screws you.

   • Ben Zemm
     Posted 01/03/2012 at 12:00 am | Permalink | Reply

     In almost all cases your language/framework should take all of the hard work out of date calculations. Many front page stories on “the daily wtf” are from programmers rolling their own version of what is available – less work to not reinvent the wheel. Feb 29 isn’t really an edge case anyway! I know a lot of my code will have issues getting close to 2038 if still running on 32 bit int machines, but 64 bit is getting very common.

3. David
   Posted 01/03/2012 at 9:46 am | Permalink | Reply

   I use Filemaker’s oBento database quite frequently and tried to enter the date yesterday. I typed 29-02-12 and it decided I had entered an impossible date, so converted it to February 12, 2029.

   Sigh.

4. @pblakez
   Posted 02/03/2012 at 7:40 am | Permalink | Reply

   Whilst the Y2K was mostly an irritation I know of one company with over 300 workers who could not process their payroll for three weeks, esp. bad in that most of the staff where on holiday an expecting direct deposits in their bank and could not drive to work to pick up cash, some were overseas, some in remote areas.

   If you had been at that site and called the y2k bug trivial (“the complete lack of any actual problems) you would have been lynched, as its was there were threats of violence and there were some very rough customers in that workforce!

   It all came down to the payroll manager who refused to have his laptop & software audited for y2k probs, every other computer in the company was audited.

5. Mike
   Posted 02/03/2012 at 10:44 am | Permalink | Reply

   As a green IT recruit in a large hospital (back in ’99) it was a great first hand experience to see what was done to remove potential risks. A lot of money was spent auditing server and client machines but the reality of that was we knew what needed to be done prior to the event. It was great to hear people say that Y2K was a non event – it meant we had done a good job.

   I’ve moved on from desktop support in to application development and project management, and it really did amaze me yesterday how many (off the shelf) systems we have that did not factor in the leap year. Lots of missed reports and mission critical maintenance systems that did not run (until manually kicked off).

6. Brian
   Posted 05/03/2012 at 12:38 pm | Permalink | Reply

   At the time I was working on a legacy DOS manufacturing system in a number of sites, that should have been EOL’d a long time before but customers were too tight to upgrade. A huge amount of time and resources thrown at ensuring a system originally designed to run from floppies in the mid 80s kept going.

   Long since moved on, but apparently a handful of sites are STILL running this system today…