For purely 32-bit software, you're pretty much screwed.

But, most if not everything I use on Linux is compiled for 64-bit x86_64 so the wrap around for time is quite ridiculous and I'll be dead before it even hits that point.

I have no idea what happens with 32-bit software running under Linux (either Wine or proprietary ports of Windows games from the 00's) if your system time is past the year 2038.

It's not a bug, it's a feature ... 🙂

chinny22 wrote on 2022-09-24, 12:46:

Roughly 15 years isn't all that long if you consider a lot of us are still messing round with pre 2007 era software (and no I can't believe 2007 is 15 years ago either)
Am I worried? no. worst case I'll just set the date to something where the days line up. 1999, 2010, 2021 or 2027 for example it just caught me off guard is all

Not worried? Oh my.. 😢 The wonderful 90s will be ~40 years ago by then.

"Hey, do you remember watching Babylon 5 and Deep Space 9 when it aired?"

"Sure, I just told my grandson last weekend when we watched the stream for the 45 anniversary of Babylon 5!
He asked me about the moon landings, too! "

Yikes! That's so bitterly sad! 😭

If anyone here is interested in OpenBSD, they converted all internal timestamps to 64 bits in the May 2014 release (OpenBSD 5.5). I thought it was cool how quickly they got ahead of the issue. :)

time_t is now 64 bits on all platforms.
From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC.
The entire source tree (kernel, libraries, and userland programs) has been carefully and comprehensively audited to support 64-bit time_t.

https://www.openbsd.org/55.html

Has anyone tried putting their 32bit system to 2038 yet? I wonder how the FAT file system is going to handle this.

I also wonder how many shady companies are going to try to make money off this by scaring the public.. all that 'Y2K-proof' nonsense was horrible.

Hezus wrote on 2022-09-24, 17:24:

Has anyone tried putting their 32bit system to 2038 yet? I wonder how the FAT file system is going to handle this.

I didn't, but somehow some of the files on my DOS/9x system ended up with timestamps in the 2090s, instead of 1990s. Or maybe it happened after I transferred them to an NT-based system to use within DOSBOX. Should double-check.

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.

From an internet poster (is this true?):

It is well understood that many 32-bit systems will stop working in the year 2038 when the 32-bit time_t overflows.
On the other hand, MS-DOS, which internally uses a 1980 year-epoch with a byte-sized year counter (and does not use a seconds-based epoch unlike Unixes), will be fine up to 2107, and Windows NT's timekeeping has a range of approximately 30000 years. Despite the elegance of the 1970 seconds-epoch, it's interesting to see how other systems designed roughly around that time period, a little later but not by much, chose to do something else, and as a result became quite a bit more future-proof.

Also found this in the same Hacker News thread:

It's still pointless because no MS-DOS system will be alive in 2107.

Lol. Lmao.

keenmaster486 wrote on 2022-09-25, 05:02:

Also found this in the same Hacker News thread:

It's still pointless because no MS-DOS system will be alive in 2107.

Lol. Lmao.

My MS-DOS builds will be alive in 2107! They’d better be, if my grandchildren/great-grandchildren don’t want me to haunt them! 😁

I bet there will be a mad rush to patch old software during the 2030s to avoid the consequences of shortsighted timestamp design.

The DOS clock is implemented as a CLOCK device (aka CLOCK$).
It syncs during boot with the physical Real-Time Clock (use CheckIt to check deviation/drift/discrepancy).
It might be possible to replace this device by a TSR.
https://en.wikipedia.org/wiki/Category:DOS_device_names

Otherwise, it might be possible to use a modified FreeDOS, Caldera DOS, PTS DOS, PC-MOS/386 or just recompile MS-DOS from the sources with some modifications.

After all, it doesn't matter so much how MS-DOS handles time information.
Rather, it matters how it provides it to DOS applications.

keenmaster486 wrote on 2022-09-25, 06:11:

I bet there will be a mad rush to patch old software during the 2030s to avoid the consequences of shortsighted timestamp design.

The more I think about this the more I wonder how far reaching the effects will be.

Windows Vista was released in 2007 which is my rough mark of when the masses started moving over to x64 but alot of software was still 32bit only.
I think the next wave of retro gamers are going to have a fair bit of community patching to do as I imagine even activation servers for old games probably have a fair bit of 32bit code and while it's no trouble to simply keep them online for now won't be bothered to fix for a game they have stopped selling years ago.

chinny22 wrote on 2022-09-25, 09:52:

Windows Vista was released in 2007 which is my rough mark of when the masses started moving over to x64 but alot of software was still 32bit only.

Hi. Sorry for replying to this one, I'll stop annoying you guys from now on here.

But I remember this time. It wasn't the developers fault back then.
In the 2000s, many devs were all excited to switch to 64-Bit computing on Windows. I was one of them.
There were two or three big reasons it didn't materialize.

a) Microsoft and other manufacturers who didn't provide 64-Bit compilers the devs wished for

b) Microsoft and stubborn users (also on Vogons) who refused to let go x86 editions of Windows (Win32 application compatibility was not endangered at any time)

c) Limited device driver support by manufacturers and Microsoft;
If only they had gotten themselves together and recompiled all their legacy drivers, just one time in history

One of the biggest issues were that no x64 compilers for VB6 and Delphi programmers existed.

The VB6 community (VB6 programmers were a silent majority) literally begged for an x64 update, even started a petition, but MS didn't react.

32-Bit Windows. The fact that x86 Windows was still newly installed and caused a dilemma for developers:

- Should I do make two binaries for Win32/Win64?
And if I do, will the average Joe understand what he/she needs to choose/install?

- Win64 is the future, so should I ditch the Win32 binary?

- Or should I just keep providing a Win32 binary so that it will run without a headache?

The latter is what most developers had choosen at the time.

If the 32-Bit editions of Windows had been phased out gracefully,
the adoption would have happened much earlier.
Or, if Microsoft had supported FAT Binaries/Universal Binaries like Apple.
Or if MS gave Windows installer the ability to install the right binary type automatically as needed.

Alas, it didn'tn turned out that way, sadly. 🙁
Here's a reminder of how people react if you confront them with obsolescence of 32-Bit software: viewtopic.php?f=5&t=81680

Jo22 wrote on 2022-09-25, 10:54:

In the 2000s, many devs were all excited to switch to 64-Bit computing on Windows. I was one of them.

Devs always love any kind of new 'standard' that will cause old products to be discarded and new ones to be bought. The motivation could not be more obvious. (And their portrayal of themselves in this process as angels from on high, leading the flock of users away from the sin of that which is old, toward the salvation of that which is new, could not be more hilarious.)

bakemono wrote on 2022-09-25, 11:43:

Devs always love any kind of new 'standard' that will cause old products to be discarded and new ones to be bought. The motivation could not be more obvious.

The motivation, as obvious as it is, from the dev's perspective is NOT related to money (if we are talking about actual devs - not companies, not big executives, etc).
From a developer's perspective, the usual motivation/reason to rejoice is the possibility of ditching legacy code that is not only getting more and more difficult to maintain as new features are implemented, but it also is the most likely cause for constant regressions.

bakemono wrote on 2022-09-25, 11:43:

Jo22 wrote on 2022-09-25, 10:54:

In the 2000s, many devs were all excited to switch to 64-Bit computing on Windows. I was one of them.

Devs always love any kind of new 'standard' that will cause old products to be discarded and new ones to be bought. The motivation could not be more obvious. (And their portrayal of themselves in this process as angels from on high, leading the flock of users away from the sin of that which is old, toward the salvation of that which is new, could not be more hilarious.)

In this specific case of 32 to 64 bit I think it was a needed change as 32bit was limiting certain things like memory allocation size and dates, so in my opinion the transition made sense.
Despite that, can't say I disagree with you on this dev mentality thing, it's a fact that the IT industry loves to reinvent the wheel again and again and many devs end up buying that romantic idea that we need to revolutionize everything all the time. This makes me sad because a lot of people in the industry end up discouraged to learn the fundamentals as they are told it's a waste of time.

Yeh I don't blame anyone.

I was one of those stubborn users. I think a big part of Vista's negative reputation is due to been the OS that dragged people willing (or more likely) not into the 64 bit world. It was always going to be a little bit painful
But at least till Win7 SP1 I was still recommending WinXP for new builds. it was familiar, had less compatibility issues, standard office PC's still weren't reaching the 4GB mark, and basically it just made IT us in the IT Dept's life much easier.
We were by no means the only company going down this line of thought so it doesn't exactly motivate companies to embrace 64 bit either, they are going to create products that support the most used system at the time.
Developing 64bit code would be good future proofing, but added expense especially if the tools didn't really exist yet, so fell into "thats a problem for next version"

chinny22 wrote on 2022-09-27, 07:28:

I was one of those stubborn users. I think a big part of Vista's negative reputation is due to been the OS that dragged people […]
Show full quote

I was one of those stubborn users. I think a big part of Vista's negative reputation is due to been the OS that dragged people willing (or more likely) not into the 64 bit world. It was always going to be a little bit painful
But at least till Win7 SP1 I was still recommending WinXP for new builds. it was familiar, had less compatibility issues, standard office PC's still weren't reaching the 4GB mark, and basically it just made IT us in the IT Dept's life much easier.
We were by no means the only company going down this line of thought so it doesn't exactly motivate companies to embrace 64 bit either, they are going to create products that support the most used system at the time.
Developing 64bit code would be good future proofing, but added expense especially if the tools didn't really exist yet, so fell into "thats a problem for next version"

I have never been an early adopter of hardware/software, but at some point I've realized that I do want to keep up with the times, as it is good brain exercise to expand my knowledge, learn new skills, adapt to new environments, etc.

I've waited till SP1 to install Vista, and wanting to future-proof my desktop that I built at the time - decided to go for the 64-bit version and install 4GB of RAM. Hilariously, I specifically hit one of those early 64bit issues - my wireless card had a buggy driver that would randomly freeze the OS if 4GB or more of RAM was installed, so I was running with 2GB for a while. Fortunately, Ralink fixed their driver bug pretty quickly, and that Vista desktop has become for a long time my most stable build. WoW64 was implemented pretty well and runs 32-bit software absolutely flawlessly, as long as 64-bit drivers are available. By late Core 2 Duo time frame, that stopped being a problem.

chinny22 wrote on 2022-09-24, 12:46:

I didn't know this was a thing!? https://en.wikipedia.org/wiki/Year_2038_problem […]
Show full quote

I didn't know this was a thing!?
https://en.wikipedia.org/wiki/Year_2038_problem

Then this morning I fired up a WinXP PC with a dying battery and decided it was 2040 for whatever reason, started Windows Media Player and gave me an error that "Your computer is set to the year 2040 which will cause Windows Media Player to stop responding"
Working backwards found 2038 was the cutoff and 2 seconds on google showed it was bigger then simply WMP.

Roughly 15 years isn't all that long if you consider a lot of us are still messing round with pre 2007 era software (and no I can't believe 2007 is 15 years ago either)
Am I worried? no. worst case I'll just set the date to something where the days line up. 1999, 2010, 2021 or 2027 for example it just caught me off guard is all

whilst it may not affect much out there in the institutional world (after the shift to 64 bit) there must be or have been major finance systems or contract systems that are already built on 32 bit that referenced future dates beyond 2038 and have already worked around it