Millennium bug. Part deux.

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

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

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

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.

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.

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

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.

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

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

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.

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

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

Not if it cost money ...

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

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.

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

...

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

Isn't the former expected to overflow in 2038?

Integers are 64-bit these days.

Which mainframes only do BCD?