Return of Y2K Bug?

[dilwyn]

I've been reading an interesting article in Computeractive magazine (issue 572) about the possible re-emergence of the Y2K bug on some older computer systems.

The Y2K bug was fixed on some systems 20 years ago to treat 2-digit year dates from 00-20 as though they were from the 2000s, rather than the 1900s. According to Computeractive, this is called "Windowing" "because it creates a date window during which a system can work". This was done to give a 20 year "fix" or grace period on the assumption that such systems would easily have been replaced by then. Sadly, some examples have emerged because as you might expect a few older systems such as retro-computer interest systems are still around 20 years later.

Anyone aware of any examples of QL software falling into this category? I would have thought that because the QL clock is based on 32-bit second counts from the first possible date (1961), so we may run into issues around 2028 on systems using signed arithmetic for the clock values, or about 2097 on systems using unsigned values.

While the clock itself, therefore, shouldn't be an issue in the short to medium term, I wonder if anyone has come across any QL software which falls foul of this through using 2 digit dates?

[RalfR]

I wonder if anyone has come across any QL software which falls foul of this through using 2 digit dates?

I remember the Sinclair version of "Cash Trader", which had this problem (later corrected by more recent versions, non-Sinclair). I wasn't able to install the freeware version on QPC2 due to errors.

The most bad problem is the SAGEsoft package of "Integrated Accounts", which I have bought in the 80s for a lot of GP, but just could used it up to the 31.12.1999. This suite is unfortunately not fully prepared with a linker (no programs to EX), you can just start the several programs with "CRUN" of the (I think) MetaComCo extensions, so perhaps not changable with an dissassembler. You can also not change the amount of VAT, this had to be done by SAGEsoft.

[tofro]

DiskMate 5 is an example - It maintains the current date as dd.mm.yy - In 2020, it simply displays "invalid date".

Tobias

[Pr0f]

Well the 32 bit seconds counter is good for 136 years

[XorA]

2038 is when old Linux versions (and a lot of Unixes) run out of time.

Probably millions still in use!

And size of time_t is coded into the applications so even if you fix the OS, all the compiled stuff still explodes!

[Pr0f]

I work with Backup software for a living - and we are seeing issues with that 2038 ctime issue already - seems that some customers want to keep backups for 20 or 25 years, and that means backups they take now would have overflowed that field - we just made it twice the size - giving dates I can't even comprehend.

We had an interesting problem with Java and libraries in countries using the Buddhist calendar, where the year is 2563

The RTC in the Gold and Super Gold cards has a 2 digit year counter, and the I2C clock chip in the Minverva MKII has a 2 digit BCD field. Plenty of RAM locations to store more digits for years though...

[XorA]

I work with Backup software for a living - and we are seeing issues with that 2038 ctime issue already - seems that some customers want to keep backups for 20 or 25 years, and that means backups they take now would have overflowed that field - we just made it twice the size - giving dates I can't even comprehend.

Thats what Linux did a while ago, 64bit time_t, but not quick enough to stop a lot of commercial software having the 32bit baked in forever