Like what you've read?

On Line Opinion is the only Australian site where you get all sides of the story. We don't
charge, but we need your support. Here�s how you can help.

  • Advertise

    We have a monthly audience of 70,000 and advertising packages from $200 a month.

  • Volunteer

    We always need commissioning editors and sub-editors.

  • Contribute

    Got something to say? Submit an essay.

 The National Forum   Donate   Your Account   On Line Opinion   Forum   Blogs   Polling   About   
On Line Opinion logo ON LINE OPINION - Australia's e-journal of social and political debate


On Line Opinion is a not-for-profit publication and relies on the generosity of its sponsors, editors and contributors. If you would like to help, contact us.


RSS 2.0

Confessions of a Y2K denier

By Chris Abood - posted Tuesday, 14 August 2007

I have a confession to make. I was a Y2K denier. During the late 90s I was asked many times were all our computers going to stop on January 1, 2000. My answer was always no. The majority of computer systems would be unaffected. Some systems (known as legacy systems) would but are already undergoing remediation. To fix the problem was relatively simple.

However, the hype of fear continued. Planes were going to fall out of the sky and missiles would launch themselves. Today, we look back and wonder what all the fuss was about. There has been much comparison between Y2K and global warming of late, so can parallels be drawn and lessons learnt?

Back in the dim dark ages of computing (the 60s and 70s) when computers occupied an entire room and had the memory capacity of a walnut shell, programmers had to devise ways of optimising their code in order to efficiently work within the bounds of computer capacity at the time. One such optimising strategy was to store the year part of a date as two digits instead of four. So 1962 was stored as 62. This was before the wide spread use of serial dates (explained later) and abundant memory capacity.


Early in the 90s it was realised that if the year 2000 was stored as 00, this could cause problems if your program engaged in date calculations, common among financial applications. For instance, if you wanted to know how long someone had been a member of your organisation, you would subtract the start year from the end year. If the start year was 1962 and the end year was 1980 then you would subtract 1962 from 1980. If the year were stored as 62 and 80 then there would be no problem. However, if the end year was 2000 and the year was stored as 00 you would get an incorrect figure.

The Year 2000 bug (aka Y2K) was perhaps the greatest swindle perpetrated by people purporting to be computer professionals.

I remember the meetings. “It has a date, it has a date. It has to be remediated, it has to be remediated”, the consultants would shout. “Well no, the program is unaffected by the ‘so called’ Y2K bug, the date that is used is for display purposes only and is stored in the database as a serial date” I would counter.

This was not what the consultants wanted to hear, for this meant that if they were unable to “remediate” the program, then they would not be able to charge four weeks worth of consultancy fees for work that should take no more than an hour.

After the meeting the consultants would get into the manager’s ear and tell them that if the program was not remediated and something went wrong on Y2K day, then it would be their head on the chopping block.

For quite some time before Y2K day, dates were stored in what is called a serial date (or more formally called a Julian date). A serial date is simply the number of days from a base date. For instance, the base date for Microsoft Excel is 0 January, 1900. So, 1 Jan 1900 serial number is 1 and 8 Jan 2007 serial number is 39090*.


Once you know the base date and the serial date, then it is just a simple formula to find the date in the format you require. 1 Jan 1900 (serial date 1) was a Monday, so every 7 days from this date is a Monday (serial date 8, 15, 22 and so on). To calculate the day of the week from a serial date we would use the formula: serial date minus the integer (an integer is a whole number) part of the serial date divided by seven then multiplied by seven. So to find the day for 8 Jan 2007, the formula would be [39090 - Int (39090 ÷ 7) x 7] which is 2. In Excel, day 1 is Sunday**, so 8 Jan 2007 is a Monday. 1 Jan 2000 is just another serial number (36526).

So why did the manager believe the consultants, most of whom got their qualifications from reading Windows for Dummies as opposed to someone like me, a person with a bachelor and masters degree in information technology? Fear and a lack of understanding of information technologies.

But there was also something else that the managers had a vested interest in: scaring the politicians. For some time the Australian Taxation Office had argued that Y2K remediation was to be capitalised. In the 1998 budget, the Federal Government announced that Y2K remediation was an expense. This change in accounting of Y2K work turned out to be a blunder on the part of the Federal Government as it provided companies with an enormous tax advantage. All of a sudden, everything within a company was a Y2K project.

  1. Pages:
  2. Page 1
  3. 2
  4. All

Discuss in our Forums

See what other readers are saying about this article!

Click here to read & post comments.

17 posts so far.

Share this:
reddit this reddit thisbookmark with Del.icio.usdigg thisseed newsvineSeed NewsvineStumbleUpon StumbleUponsubmit to propellerkwoff it

About the Author

Chris Abood is a teacher and computer programmer. He has taught at TAFE and private RTOs, and has worked as a computer programmer mainly in banking and finance. He is concerned with the effects and use of technology within society. These opinions are his own.

Other articles by this Author

All articles by Chris Abood

Creative Commons LicenseThis work is licensed under a Creative Commons License.

Article Tools
Comment 17 comments
Print Printable version
Subscribe Subscribe
Email Email a friend

About Us Search Discuss Feedback Legals Privacy