Millennium bug. Part deux.

[Jethro_uk]

Parking meters, cash registers and a professional wrestling video game have fallen foul of a computer glitch related to the Y2K bug.

The Y2020 bug, which has taken many payment and computer systems offline, is a long-lingering side effect of attempts to fix the Y2K, or millennium bug.

Both stem from the way computers store dates. Many older systems express years using two numbers ? 98, for instance, for 1998 ? in an effort to save memory. The Y2K bug was a fear that computers would treat 00 as

1900, rather than 2000.

Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code, or adopt a quick fix called ?windowing?, which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 per cent of computers fixed in 1999 used the quicker, cheaper option.

?Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road,? says Dylan Mulvin at the London School of Economics

[Pancho]

There has always been loads of ways to mess up dates.

In the 1990s we used a package that used a date format based upon seconds form a fixed date (I think 1-Jan-1970). The trouble was they stored dates as 4bytes. Around about 19-Jan-2038 dates went back to something like 13-Dec-1901. That took a while to figure out :-)

Other f*ck ups - Excel has 29-Feb-1900. (not their fault, they were copying Lotus 123)

But the coolest version of a programmer getting it right can be seen from a Linux bash terminal, type:

$ cal 9 1752

[Jethro_uk]

Well the US insisting on their unique format was always the best.

[Pancho]

Talking of nationalistic countries look at the etymology of UTC. Management by committee, no one happy.

[Geoff Clare]

It's only right if you are in the UK or one of its (former) colonies. I've get to encounter a version of cal that shows, for example:

$ TZ=Europe/Rome cal 9 1752

as a normal month and:

$ TZ=Europe/Rome cal 10 1582

as the "special" one.

[Bob Eager]

Hardly just a Linux thing. That can be found in UNIX systems that pre- date Linux by a long way.

In fact, it was in the UNIX I used in 1975.

[Brian Gaff (Sofa)]

Well we knew that.Are we saying then, that in the intervening 20 years the code has not changed? Surely nobody uses code that old. Brian

[Jethro_uk]

There are plenty of outfits where 20 year old code would be expected to be under warranty.

Remember the whole millennium bug sprang from people using code written in the 60s.

Anyway, having seen what passes for code in 2020, I'd feel a lot better knowing there's a good wedge of 20 year old code around.

[Pancho]

Quite right, but gosh, you would be a tough taskmaster.

[Pancho]

I know, one was trying to be down with the kids.

[Andrew]

GAN insurance co in Croydon had all their general, motor, shipping insurance systems written like this with the day in YYMMDD form as the most significant part of the key to many indexed sequential files.

We just went through all the code (thousands of programs and modules) made sure all attempts to do an indexed read or add a new record or add/update any date, used a common module that extended the YY part of the date using ascii characters that extended beyond 0-9.

Since dates of birth and other old historical insurance dates were the most common date held in YYMMDD form, just 'adding' 20 years onto the date wouldn't work.

[Andrew]

ROFL. Banks are terrified of changing ancient legacy code because of the nightmare of a) having any staff who still know everthing about all the changes that have been made over the 40+ years that some of their core systems have been running (on ever faster processors) and b) finding a way to prove that they have tested all possibilities.

Andrew

[Max Demian]

Why didn't they use 40 or 50 rather than 20, then they would be retired or dead by the time it failed. For that matter, there would have been

80+ year-olds whose DOB would malfunction by the 20 method. Didn't people test the code before releasing it?

[Jethro_uk]

Not if it cost money ...

I wonder how many people here recognise a phrase along the lines of "Recharge to sales" ?

[Tim Streater]

Anyone who stores a date as, f'rinstance, 20-Dec-1999 or Dec 30, 2020, is a looney. The proper way to do it is to take the date you're given, and convert it to seconds since the epoch (01-01-1970), and store it as an integer or quite likely a double in your database. Even using the latter, you're good for almost 170 million years.

Then if you need to present the date to a user, you convert it to their preferred format and time zone.

[michael adams]

What was the practical reason for deciding to convert and store dates in the form of seconds ? Rather than days.

As there are 86,400 seconds in each and every day, why was it thought desirable to store numbers 86,400 times larger than they needed to be ?

Obviously if it was a matter of storing times and dates then that would be different. Was it the case that the idea of storing times fell by the wayside in the interim, but nobody bothered to change the procedure ?

michael adams

...

[The Natural Philosopher]

ot of all you have is a mainframe that does binary coded decimal ONLY

And all your COBOL language supports is 'numerical' which is an array of binary coded decimal digits. as long as you specify in your 'data dictionary' MOST Y2k issues were in legacy COBOL applications

[Pamela]

Isn't the former expected to overflow in 2038?

[Tim Streater]

Integers are 64-bit these days.

[Tim Streater]

Which mainframes only do BCD?