Hacker News Reader

Comment by M4v3R | Hacker News Reader

2038 is going to be an interesting year that’s for sure. I’m big into Final Fantasy VII modding/speedrunning and while reverse engineering the game I stumbled upon some code that actually checks if the current date is before 2038. If it’s not it refuses to run. I have no idea why they put this kind of check in the game's code, I tried to remove it but the game actually still didn’t start so there is probably some issue that prevents it from working when the date overflows.

I can only imagine that a lot of other legacy software will have similar issues when we reach year 2038.

View on HN

> I stumbled upon some code that actually checks if the current date is before 2038. If it’s not it refuses to run. I have no idea why they put this kind of check in the game's code,

That's actually very clever. Instead of crashing in unexpected ways or doing odd things, just cleanly exit. If you really want it to run after 2038, you have to emulate the clock, which would then avoid these potential Y2038 bugs.

Clever would be fixing the Y2038 bugs. This sounds more like a lazy/overworked programmer getting a QA bug report and marking it as WONTFIX because 2038 is going to be someone else's problem.

To clarify: Clever would be to to spend several days hunting down a bug that will affect 0.0001% of your users, and has an easy, well-known workaround?

It's going to affect 100% of your users in 2038. So yeah, if you see the game as just a product with a limited lifecycle then sure you can make excuses for cutting corners. If you see the game as a piece of art then you should have some interest in it working in the future. It's not like time_t overflows are rocket science.

Although the most clever solution would be to not have any bugs in the first place ofc ;)

Yeah, but at least they actually typed //WONTFIX

It will break earlier because unix time isn't only a display format. Tons of calculation are scheduling things into the future. But if the future ends up being in the past? Then you will have problem now. Starting from things with 10 year cycle, 5 year, yearly, monthly, daily. The more nearer to 2038, the more things explodes.

Definitely. I was charged with fixing Y2K problems at a hospital in the late 90ies. The software scheduling checkups for pregnant women was first, because it had the estimated birth date, i.e. up to 9 months ahead.

Is this in the ps1 version, the pc port, or are we talking the remake or something else?

The PS1 didn't have a real time clock, so that's ruled out.

Keep in mind that FF7 originally had a PC version around launch (that's the version I first played) so it's quite plausible that all versions could have this code if it dates to the original. Don't think it would have made sense to have it on the PS1, though.

Every port of Final Fantasy VII (PS4, Switch, Android, Xbox One, etc) is just the original 1998 PC port EXE running in an emulation layer similar to Wine. The general consensus in the community is that Square has either lost the game's source code or feels that doing things this way is safer than rebuilding the code. In a fairly forward-thinking move, FF7 PC has the ability to use an external DLL as its graphics driver, so the ports use this functionality for new graphics drivers that allow for higher resolutions and more modern APIs than the DirectX 5 support the game shipped with.

How does that work on the ARM based targets like Switch and Android? Some kind of binary translation?

It runs the x86 code in an emulator.

Wow, what kind of controller button prompts does each version provide?

Each version has the correct button prompts for its controller. I don’t know enough about FF7 to know how this was accomplished, probably by editing the script files. One thing you might be interested in- there’s evidence that the team responsible for the new FF7 renderer code either hired a modder to write it or used his code as a base. https://blog.julianxhokaxhiu.com/2020-02-19-final-fantasy-vi...

I owned that one. It was a tricky thing to install back then on my pentium 2, 255mhz. Could get the graphics to work without glitches or the sound but not both at the same time. :D

How will this stack up compared to the Year 2000 bug? Better? Worse?

I think a lot of systems, a lot of them embedded, will fail in odd ways. Y2K was mostly a data format issue. This is much more interesting (and widespread).

Wasn't the y2k issue programs that stored numbers as binary coded decimal and only allocated one octet (i.e. two digits) to the date?

BCD could be one of many problems, but ASCII strings would me more common in systems I dealt with. There were a lot of assumptions about two digit years that maybe made sense sometime in the 70s for code that you didn’t think would survive more than a few years.

Also take a look at struct tm. Its tm_year looked like just a 2 digit year and as such people may format it with printf(“19%02d”,…). It is actually the number of years since 1900. In early 2000 I had to fix a broken ftp server that was sending 19100 as the year.

The only manifestation of Y2K that I ever saw was a receipt with the date 1/2/100.

I saw that in websites with Perl-generated dates.

Y2038 is also a data format issue (32-bit dates).

I think it's likely to be better handled, but at the same time people keep citing the non-disaster of Y2K as a reason not to do disaster preparation, so I don't know.

True, but it's not like a birth date - this one goes very deep into the core of the operating system.

My sense is that it'll be a lot worse, Y2K was only a data format issue, whereas 2038 issue has to do more with underlying hardware. It really all depends, and we'll see. Certainly, many old software will stop working in 2038.

I'd say both are a data format issue, y2k was usually at a higher level and occured in custom data formats of individual software, while 2038 is in the OS and basic libraries, or even in hardware.

I do think though there were some bioses that messed it up too, so that's rather low level too.

For systems running in finance, the problem should have already shown up when calculating dates for 30 year bonds and mortgages. But as another poster said, there's a ton of embedded systems out there running Linux that likely aren't handling it correctly.

Those 30 years bonds would have been opened in 2008, about the time of the last recession.

Total coincidence, but fun to think of the conspiracy theory :D

Considering the amount of devices we have now, and the devices and applications we'll have in 16 years..

In spite of knowing about this issue in 2038, registering a lot of domains to the affect and hoping I can burst out a lot of contracting work that year, make bank and retire.

I use EPOC time in my own code NOW, a lot... :-/

I’m assuming by EPOC you’re talking about Unix timestamps? There’s nothing wrong with them if they’re 64-bit.

As I understand it, it seems like it’s mostly software using 32-bit integers that will struggle.

So if you’re writing modern code on a modern runtime running on 64-bit platforms you should be fine (easy to verify by changing your dev environment’s clock).

Nothing wrong? You say that now, but just wait until the year 292277026596!

Nah, just switch to unsigned 32bit, much easier fix and someone will probably have figured it all out until that becomes a problem! ;-)

Some (many?) currently-updated 32-but OSS have been changed to use a 64-bit timestamp now, too.

On recollection there's definitely a non-zero number of 32 bit machines I worked on up until I quit my last job.

Out of support, aging 32bit SPARC hosts running 4.6c SAP.

> Out of support, aging 32bit SPARC hosts running 4.6c SAP.

That's production!

Are there any good mitigation strategies published somewhere?

find "int32"

replace "int64"

I kid, fixing this will require an even greater amount of effort compared to the Y2K bug considering how many more linux devices have been deployed since then.

Consider how many of those linux devices are difficult or impossible to update, and you start to realize the mess we'll be in. At least Y2K affected systems that by and large could be updated easily.

It all depends. We have more devices and software now, but a lot more critical stuff is centrally hosted by cloud providers that'll be ready long before the deadline.

Oh much better, for sure, it'll be so much worse...

Reply on news.ycombinator.com