VOGONS


Year 2038 bug?

Topic actions

Reply 20 of 39, by diegoparedeshd1

User metadata
Rank Newbie
Rank
Newbie

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

Reply 21 of 39, by diegoparedeshd1

User metadata
Rank Newbie
Rank
Newbie

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

Reply 22 of 39, by dr_st

User metadata
Rank l33t
Rank
l33t
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.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 23 of 39, by diegoparedeshd1

User metadata
Rank Newbie
Rank
Newbie
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

Reply 25 of 39, by Shagittarius

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 26 of 39, by Big Pink

User metadata
Rank Member
Rank
Member

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

I thought IBM was born with the world

Reply 27 of 39, by dondiego

User metadata
Rank Member
Rank
Member

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.

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 28 of 39, by gaffa2002

User metadata
Rank Member
Rank
Member
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.

LO-RES, HI-FUN

My DOS/ Win98 PC specs

EP-7KXA Motherboard
Athlon Thunderbird 750mhz
256Mb PC100 RAM
Geforce 4 MX440 64MB AGP (128 bit)
Sound Blaster AWE 64 CT4500 (ISA)
32GB HDD

Reply 29 of 39, by Shagittarius

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 30 of 39, by BEEN_Nath_58

User metadata
Rank l33t
Rank
l33t

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.

previously known as Discrete_BOB_058

Reply 31 of 39, by Big Pink

User metadata
Rank Member
Rank
Member

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).

I thought IBM was born with the world

Reply 32 of 39, by diegoparedeshd1

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 33 of 39, by WolverineDK

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 34 of 39, by gaffa2002

User metadata
Rank Member
Rank
Member
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.

LO-RES, HI-FUN

My DOS/ Win98 PC specs

EP-7KXA Motherboard
Athlon Thunderbird 750mhz
256Mb PC100 RAM
Geforce 4 MX440 64MB AGP (128 bit)
Sound Blaster AWE 64 CT4500 (ISA)
32GB HDD

Reply 35 of 39, by chinny22

User metadata
Rank l33t++
Rank
l33t++
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 .

Reply 36 of 39, by subhuman@xgtx

User metadata
Rank Oldbie
Rank
Oldbie
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?

7fbns0.png

tbh9k2-6.png

Reply 37 of 39, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 38 of 39, by zyzzle

User metadata
Rank Member
Rank
Member

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.

Reply 39 of 39, by davidrg

User metadata
Rank Member
Rank
Member
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.