• Our booking engine at tickets.railforums.co.uk (powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!

The Millennium Bug

Status
Not open for further replies.

AM9

Veteran Member
Joined
13 May 2014
Messages
14,265
Location
St Albans
Mod Note: Posts #1 - #17 originally in this thread.

Possibly with Article 216.

Incidentally, just what did go into stopping the 'Millennium Bug' - you don't have to reply here (would be holding up the thread) a pm will do - if you have time.
The 'millenium bug' wasn't a single fault or failure, it was the consequences of decades of programming short cuts that only represented the date as two digits - i.e. ending in 99 meaning 1999, as no computers or their operating systems were working before the 20th century and many programmers didn't forsee that their software would malfunction at the turn of the century, (the media decided that the 'millenium' was abetter headline). Each of the possibilities needed to be evaluated which is what took the time. Updating to compliant software was relatively simple but disruptive in a live system, - once it had been written, tested, certified and released.
 
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R

RailUK Forums

Modron

Member
Joined
5 Feb 2019
Messages
202
The 'millenium bug' wasn't a single fault or failure, it was the consequences of decades of programming short cuts that only represented the date as two digits - i.e. ending in 99 meaning 1999, as no computers or their operating systems were working before the 20th century and many programmers didn't forsee that their software would malfunction at the turn of the century, (the media decided that the 'millenium' was abetter headline). Each of the possibilities needed to be evaluated which is what took the time. Updating to compliant software was relatively simple but disruptive in a live system, - once it had been written, tested, certified and released.

Interesting, thanks for that.

I will admit that at the time I thought 'oh here we go, yet another scare story...' Turns out that there was a good reason to be concerned.
 

dosxuk

Established Member
Joined
2 Jan 2011
Messages
1,762
Interesting, thanks for that.

I will admit that at the time I thought 'oh here we go, yet another scare story...' Turns out that there was a good reason to be concerned.

To give you an example, while aircraft wouldn't fall out of the sky because the engines decided it was 1900 and they hadn't yet been invented, ATC could have found themselves unable to access any of the flight schedules because their computers were looking for flights in their databases from 1900 rather than 2000.

There is a similar bug getting closer all the time - the 2038 bug - which will result in some systems thinking it's 1970 again.
 

Modron

Member
Joined
5 Feb 2019
Messages
202
To give you an example, while aircraft wouldn't fall out of the sky because the engines decided it was 1900 and they hadn't yet been invented, ATC could have found themselves unable to access any of the flight schedules because their computers were looking for flights in their databases from 1900 rather than 2000.

There is a similar bug getting closer all the time - the 2038 bug - which will result in some systems thinking it's 1970 again.

Okay, so if my computer starts smoking pot and wearing CND t-shirts whilst playing Mungo Jerry records I'll know what's going wrong!
 

AM9

Veteran Member
Joined
13 May 2014
Messages
14,265
Location
St Albans
Okay, so if my computer starts smoking pot and wearing CND t-shirts whilst playing Mungo Jerry records I'll know what's going wrong!
If you have an aged unix-based system and it's operating system hasn't been maintained, yes.
 

keith1879

Member
Joined
1 Jun 2015
Messages
393
The 'millenium bug' wasn't a single fault or failure, it was the consequences of decades of programming short cuts that only represented the date as two digits - i.e. ending in 99 meaning 1999, as no computers or their operating systems were working before the 20th century and many programmers didn't forsee that their software would malfunction at the turn of the century, (the media decided that the 'millenium' was abetter headline). Each of the possibilities needed to be evaluated which is what took the time. Updating to compliant software was relatively simple but disruptive in a live system, - once it had been written, tested, certified and released.

As someone who spent 2 years solid working on this .........
The phrase "programming short-cut" implies laziness .......to some extent there was an element of saving time but it's also worth bearing in mind that in the 60s/70s computer storage was massively expensive so why bother storing "19" (and paying for it) when nobody ever wrote it out in longhand because it was redundant to understanding?? Also - it wasn't the case that we didn't foresee that the software would malfunction .....it was more that we didn't foresee that it would still be working and in place. Certainly by 1985 when I joined the software industry we were starting to include routines when comparing dates just in case the software was still around in 15 years time ....but essentially there was a very substantial underestimate of how reliable and long-lived systems would prove to be. Date comparisons involving dates of birth were particularly significant to (for example) social security systems.
 

AM9

Veteran Member
Joined
13 May 2014
Messages
14,265
Location
St Albans
As someone who spent 2 years solid working on this .........
The phrase "programming short-cut" implies laziness .......to some extent there was an element of saving time but it's also worth bearing in mind that in the 60s/70s computer storage was massively expensive so why bother storing "19" (and paying for it) when nobody ever wrote it out in longhand because it was redundant to understanding?? Also - it wasn't the case that we didn't foresee that the software would malfunction .....it was more that we didn't foresee that it would still be working and in place. Certainly by 1985 when I joined the software industry we were starting to include routines when comparing dates just in case the software was still around in 15 years time ....but essentially there was a very substantial underestimate of how reliable and long-lived systems would prove to be. Date comparisons involving dates of birth were particularly significant to (for example) social security systems.
Some areas were aware of the problems that had been stored up in the '60s but there were plenty of examples of software where the issue just wasn't even thought about, maybe because any liability (personal or product) for those problems ran out well before they were likely to arise.
 

nlogax

Established Member
Joined
29 May 2011
Messages
5,373
Location
Mostly Glasgow-ish. Mostly.
If you have an aged unix-based system and it's operating system hasn't been maintained, yes.

There are quite a few aging SPARC and other RISC-based systems out there doing Important Stuff for governments, public infrastructure and financial institutions, but I can't believe there'll be many left by 2038. Much of the work - 64 bit timestamps - to get Unix and Linux (including Android) into shape has been ongoing for some years, but I'm not sure how much of it is aligned to any overriding plan. Not that Y2K mitigation had that either.
 

Modron

Member
Joined
5 Feb 2019
Messages
202
If you have an aged unix-based system and it's operating system hasn't been maintained, yes.

I don't think mine's quite that old, though I've had it for six years so I guess in computing terms it's an antique.
 

Modron

Member
Joined
5 Feb 2019
Messages
202
What has the Millennium Bug to do with the Brexit?

Some posters decided to comment on what was intended to be a passing comment of mine related to Moral Panic, and that it would seem to be the case that the panic over Brexit is just another one of those things.

There are people who just don't care about these stories anymore, they just want it done and for some peace.
 

dgl

Established Member
Joined
5 Oct 2014
Messages
2,412
One of my keyboards (of the musical variety (specifically a Generalmusic S2) has a weird version of the millennium but where it only allows 2 digit years (despite showing them as 4 digits) and the last year it will allow you to input is 12, the strange thing being that it does support displaying the date past 2012 but only by setting the date by 2012 at the latest and just letting it run. If you attempt to change the year at anytime (as i stupidly did) then you are stuck and can't correct it.

Also a lot of the millennium bug (if it has not already been said) was not just down to laziness but to saving a couple of bytes, important when early computers had so few of them.
 

AM9

Veteran Member
Joined
13 May 2014
Messages
14,265
Location
St Albans
... Also a lot of the millennium bug (if it has not already been said) was not just down to laziness but to saving a couple of bytes, important when early computers had so few of them.
And a lot of it was down to sloppy code writing or OS maintenance. Several HP scientific computers had to be replaced where I was because HP wouldn't provide HP-UX updates for them. The cost of that wasn't just a bit of code to fix date records, - it resulted in a complete rewrite of many application programmes to run on a new Linux platform run on industrial PCs. If softies knew about the pitfalls of early code in the '60s, they conveniently forgot it for about 25 years until the whole issue became a panic.
 

Giugiaro

Member
Joined
4 Nov 2011
Messages
1,130
Location
Valongo - Portugal
A good thing that came up from the Y2K bug was that the infrastructure was widely modernised and brought up to date. Imagine being in 2020 with banks and state services still running old slacking mainframes.

My university runs a 32bit based Windows NT 3.1 server for most academic services. That thing will eventually have to go before 2038, if it manages to last that long...
 

JamesT

Established Member
Joined
25 Feb 2015
Messages
2,691
A good thing that came up from the Y2K bug was that the infrastructure was widely modernised and brought up to date. Imagine being in 2020 with banks and state services still running old slacking mainframes.

My university runs a 32bit based Windows NT 3.1 server for most academic services. That thing will eventually have to go before 2038, if it manages to last that long...

That’s an impressively out of date system. However Windows itself doesn’t suffer from the 2038 problem, it uses a different counter for time. Applications running on top that have used the libc interface for time data may still be at risk.
 

Jonny

Established Member
Joined
10 Feb 2011
Messages
2,562
The easiest fix would be to apply a modulus (remainder of division) command to the time when its value gets too high; once this has kicked in it would trick the computer into thinking that it is at an earlier time. Also, most programming languages have try/except or try/catch statements where any likely error can be contained without undue effect.
 

Bletchleyite

Veteran Member
Joined
20 Oct 2014
Messages
97,873
Location
"Marston Vale mafia"
The easiest fix would be to apply a modulus (remainder of division) command to the time when its value gets too high; once this has kicked in it would trick the computer into thinking that it is at an earlier time. Also, most programming languages have try/except or try/catch statements where any likely error can be contained without undue effect.

There's a far easier way to solve it - increase the size of the integer in which the date value is stored. As most machines are now 64 bit this should not be difficult.

Unlike the Y2K bug it's just a case of a number getting bigger (and potentially overflowing), not the need to prepend it with 19/20 as appropriate.
 

krus_aragon

Established Member
Joined
10 Jun 2009
Messages
6,045
Location
North Wales
That’s an impressively out of date system. However Windows itself doesn’t suffer from the 2038 problem, it uses a different counter for time. Applications running on top that have used the libc interface for time data may still be at risk.
Though as it happens, Windows 95 could crash after 49.7 days, because at that point (2^32 miliseconds after boot) an internal counter would overflow back to zero, and any programs that used that counter for timestamping their activities might malfunction. This was only discovered in 2002: https://www.cnet.com/news/windows-may-crash-after-49-7-days/
 

nlogax

Established Member
Joined
29 May 2011
Messages
5,373
Location
Mostly Glasgow-ish. Mostly.
Though as it happens, Windows 95 could crash after 49.7 days, because at that point (2^32 miliseconds after boot) an internal counter would overflow back to zero, and any programs that used that counter for timestamping their activities might malfunction. This was only discovered in 2002: https://www.cnet.com/news/windows-may-crash-after-49-7-days/

To be fair the concept of a Win95 box staying up for anywhere approaching that long has always been pretty fanciful.
 

Ken H

On Moderation
Joined
11 Nov 2018
Messages
6,304
Location
N Yorks
i found 2. I had vehicles immediately going out of warranty on 1/1/97. program was adding 3 to the year to get warranty expiry. 97 + 3 = 100, lose the hundreds because its only a 2 character field, so get 00. 97 is greater than 0 so vehicle out of warranty.

Lot tracked product. lot number was year and month of manufacture date. so product made this month would have lot 1902
You pick the lowest lot number product. so in Jan 2000 they started picking stock lot 0001 instead of stock made in 1997.
 

Giugiaro

Member
Joined
4 Nov 2011
Messages
1,130
Location
Valongo - Portugal
As most machines are now 64 bit this should not be difficult.

Consumer and Enterprise machines are indeed mostly being replaced by 64 bit computers. I can't really understand if ARM devices are 32 or 64 bit, a quick search on Google was more confusing than clarifying, though I could understand that most apps designed for ARM are 32 bit.

The biggest problem is in two fronts: One, Software, and Two, Embedded Machines and IoT's.

I've seen several ATM's, Infotainment screens and other public machines that are incredibly old or use a pirated copy of Windows 95 or 98. And experience tells that as long as they work, they'll be around, unless some major security issue renders them undesirable.
 

dgl

Established Member
Joined
5 Oct 2014
Messages
2,412
ARM is a mix of 32bit and 64bit, with most processors being of the 32bit variant (I would assume given the amount of cheap ARM SOCs available).
Further to that only certain versions of new(er) ARM processors support 64bit and that is primarily for the mobile phone market.
 

bussnapperwm

Established Member
Joined
18 May 2014
Messages
1,510
A good thing that came up from the Y2K bug was that the infrastructure was widely modernised and brought up to date. Imagine being in 2020 with banks and state services still running old slacking mainframes.

My university runs a 32bit based Windows NT 3.1 server for most academic services. That thing will eventually have to go before 2038, if it manages to last that long...

So probably as long as a pacer (even past global thermonuclear war!)
 

johntea

Established Member
Joined
29 Dec 2010
Messages
2,602
I remember updating a library system via floppy disk, 'ah yes your book is due back on 1st January 1900!'

Legacy systems can be annoying and difficult to replace sadly, I work in NHS IT and you get a lot of very expensive medical hardware come with such delights as XP embedded which you can never upgrade until you replace the entire piece of kit (£££!). Personally if I was developing similar hardware I would create some sort of modular slot for a separate PC/laptop so it could be swapped out at some point for a slightly more up to date OS build but hey what do I know!
 

nlogax

Established Member
Joined
29 May 2011
Messages
5,373
Location
Mostly Glasgow-ish. Mostly.
. Personally if I was developing similar hardware I would create some sort of modular slot for a separate PC/laptop so it could be swapped out at some point for a slightly more up to date OS build but hey what do I know!

Medical hardware and embedded OS, one of those problems VDI can't address. And I'm sure those equipment manufacturers charge a small fortune for any possible upgrade that falls short of a full replacement.
 

underbank

Established Member
Joined
26 Jan 2013
Messages
1,486
Location
North West England
I've seen several ATM's, Infotainment screens and other public machines that are incredibly old or use a pirated copy of Windows 95 or 98. And experience tells that as long as they work, they'll be around, unless some major security issue renders them undesirable.

I'm still using an early 1990's MSDOS PC running a dos version of Lotus 1-2-3. Obviously, we also have lots of modern PCs using windows too, for "real" work, so the old dos Lotus is more for novelty/fun, but we crank it up quite often, and everything still works on it - we're just keeping it going to see how long it manages. (The "wave" of numbers changing across the screen is really theraputic - shame it can't be replicated on modern spreadsheets). It's also useful as it's the only machine in the office with a floppy disk drive so it gets cranked up when someone sends us their data on a floppy disk (we still have a couple of clients using dos 1-2-3 for their invoicing/accounting who can only send us data by floppy!).
 

najaB

Veteran Member
Joined
28 Aug 2011
Messages
30,820
Location
Scotland
If it does conk out you can get USB floppies.
I thought the last manufacturers of disks had shut down about a year or two back? Or was that just Sony (inventor of the 3.5" hard floppy).

As an aside, the Minuteman II control software is loaded using real floppy disks!

[Although the linked story says that the floppy disks would be replaced in 2017, they still hadn't up until the middle/end of 2018]
 
Status
Not open for further replies.

Top