set the date to 2039 and try games like half life 2, half life 1, black mesa, hard reset redux,gta iv, shadow warrior 2013 and some when trying to save the game they crashed or others if they let save it but when loading the game they crashed

I also tried serious sam 2, elder scroll oblivion and they did not open when setting the date to 2039 , instead the suffering lets you save the game but when loading it it crashes if the date is 2039 .so this problem is going to affect a lot of classic games

diegoparedeshd1 wrote on 2022-09-27, 13:59:

set the date to 2039 and try games like half life 2, half life 1, black mesa, hard reset redux,gta iv, shadow warrior 2013 and some when trying to save the game they crashed or others if they let save it but when loading the game they crashed

I also tried serious sam 2, elder scroll oblivion and they did not open when setting the date to 2039 , instead the suffering lets you save the game but when loading it it crashes if the date is 2039 .so this problem is going to affect a lot of classic games

Did you test on a 32-bit OS, or a 64-bit OS? Because most 32-bit games run in a 64-bit OS just fine, but if it is the game itself that has problems, regardless of OS, then it is a much bigger issue.

dr_st wrote on 2022-09-29, 14:06:

diegoparedeshd1 wrote on 2022-09-27, 13:59:

set the date to 2039 and try games like half life 2, half life 1, black mesa, hard reset redux,gta iv, shadow warrior 2013 and some when trying to save the game they crashed or others if they let save it but when loading the game they crashed

I also tried serious sam 2, elder scroll oblivion and they did not open when setting the date to 2039 , instead the suffering lets you save the game but when loading it it crashes if the date is 2039 .so this problem is going to affect a lot of classic games

Did you test on a 32-bit OS, or a 64-bit OS? Because most 32-bit games run in a 64-bit OS just fine, but if it is the game itself that has problems, regardless of OS, then it is a much bigger issue.

Tested on Windows 10 64-bits.
the error occurs when putting a higher date on Windows clock than the one indicated in the Wikipedia article and running a 32-bit game, I only tried these games but it is very likely that it will happen in many more games
https://en.wikipedia.org/wiki/Year_2038_problem

Ouch.

So after that date I'll have to run all my retro systems on the wrong time?

Calendars repeat. 2027 matches 2038, so you can throw the system time back 11 years and still have all the days line up.

With the year 2000 bug the bios date of my 486dx4 changed to 2094 (award) and my dos filesystem was nuked, i had to set a previous date and reinstall.
I had nothing of value, i only used it for games soon later i switched to a pentium 133.

Big Pink wrote on 2022-09-29, 17:27:

Calendars repeat. 2027 matches 2038, so you can throw the system time back 11 years and still have all the days line up.

That's actually a very good idea. Hope I remember your post in 2038.
It seems this bug cannot be solved with a simple fix or update as depends on how each software uses/stores the date. For hobbyists like us, it's just a matter of changing the system date, so I'm not worried about how my old stuff will behave.
The real concern though is for software still being used by the industry, small businesses, etc. Some people will start having random issues after the date without having any idea why.

gaffa2002 wrote on 2022-09-30, 11:30:

That's actually a very good idea. Hope I remember your post in 2038. It seems this bug cannot be solved with a simple fix or upd […]
Show full quote

Big Pink wrote on 2022-09-29, 17:27:

Calendars repeat. 2027 matches 2038, so you can throw the system time back 11 years and still have all the days line up.

That's actually a very good idea. Hope I remember your post in 2038.
It seems this bug cannot be solved with a simple fix or update as depends on how each software uses/stores the date. For hobbyists like us, it's just a matter of changing the system date, so I'm not worried about how my old stuff will behave.
The real concern though is for software still being used by the industry, small businesses, etc. Some people will start having random issues after the date without having any idea why.

Rather than 2027, I'd go back to the farthest back date possible that matches, that way you can sorta track time signatures if you ever need to instead of having to reset again in another 11 years.

I tested Dungeon Keeper (DirectDraw version) and it seems Y2038 incompatible. However, the Direct3D version is compatible. Probably Bullfrog took some notes and fixed it in the new version.

Interestingly, Dungeon Keeper D3D stops working on 18th January 2038, and since DxWnd doesn't have a fake time control yet, I didn't check at which time it happens. The game will also run in any date before 31 December 9999 starting from 1 January 1601.

Found this tool https://www.timeanddate.com/calendar/repeatin … .html?year=2038

Restarting from 2010 looks like it holds the pattern for 28 years up until hitting 2038 again (2010 matches 2038, 2011 matches 2039, 2012 matches 2040... 2037 matches 2065).

BEEN_Nath_58 wrote on 2022-09-30, 17:01:

I tested Dungeon Keeper (DirectDraw version) and it seems Y2038 incompatible. However, the Direct3D version is compatible. Probably Bullfrog took some notes and fixed it in the new version.

Interestingly, Dungeon Keeper D3D stops working on 18th January 2038, and since DxWnd doesn't have a fake time control yet, I didn't check at which time it happens. The game will also run in any date before 31 December 9999 starting from 1 January 1601.

The best solution to this problem is for Microsoft to somehow lock the date of 32-bit applications to a date before January 19, 2038 so that applications cannot read beyond that date.

What will the year 2038 bug do in Linux ? That seems more interesting, if you ask me.

WolverineDK wrote on 2022-10-02, 10:32:

What will the year 2038 bug do in Linux ? That seems more interesting, if you ask me.

If I understood correctly, the issue can happen per software. So it depends on how each application stores and handles dates.

Shagittarius wrote on 2022-09-30, 14:21:

Rather than 2027, I'd go back to the farthest back date possible that matches, that way you can sorta track time signatures if you ever need to instead of having to reset again in another 11 years.

Some software may be smart enough to go "system says it's 1943 that cant be right I was written yet" and cause an error but i'm sure everyone will manage to find their "magical" year that suits their needs as lets face it absolute accuracy isn't really needed for our purposes here .

leileilol wrote on 2022-09-25, 02:57:

There's been quite a few malformed dates on files back in the day that seemed to work fine, apart from making binary patchers and sync/backup utilities upset.

24/12/1996?

oh i don't mean filthy torrentzip whore dates, i'm talking about the year 2094 or so during the 90s - either from corrupt files recovered or probably MacOS finder residue files. The latest non-corrupt file I have on my floppies is allegedly from the year 2197.

I think just making time t an unsigned 32-bit number would solve a lot more problems than it causes. How often do programs need to use *negative* dates? Everyone says making the 32-bit date unsigned is a problem, but it would at least make most software which uses 32-bit dates (elapsed seconds since 1-1-1970) function until the year 2106 without strange phantom overflow bugs.

zyzzle wrote on 2022-10-02, 21:34:

I think just making time t an unsigned 32-bit number would solve a lot more problems than it causes. How often do programs need to use *negative* dates? Everyone says making the 32-bit date unsigned is a problem, but it would at least make most software which uses 32-bit dates (elapsed seconds since 1-1-1970) function until the year 2106 without strange phantom overflow bugs.

This is what DEC did to OpenVMS back in 1998 when doing the Y2K work. time_t is an unsigned 32bit integer so things should keep working until 2106. The native OpenVMS time APIs are good until the year 31086. So your 32bit VAX from the 80s should be fine for the rest of this century if not longer as long as its running OpenVMS, not UNIX.

Windows NT is much the same - the native Win32 APIs will handle dates out to the year 30827 just fine but anything using time_t rather than SYSTEMTIME or FILETIME that was compiled with Visual C++ 2003 or older will have trouble (in Visual C++ 2005, time_t became 64bit).

So 32bit CPUs aren't a problem. And if you're not running a 32bit UNIX your operating system may not be a problem. The real problem is that storing and manipulating time as an integer turns out to be pretty convenient. And the easiest way to do that is using time_t which is usually a 32bit signed integer. So there will be plenty of file formats and probably a few network protocols out there that will break after 2038 just because storing time as a 32bit integer was easier than serialising the SYSTEMTIME struct.