The code that reoccurs the Year 2038 problem has been copied to many places.

The Year 2038 problem is that the program malfunctions due to a UNIX time overflow, but most programs have already solved it. However, game development engineer Adrian found code in Microsoft's documentation that caused the Year 2038 problem. The program that copied the code warns that a year 2038 problem will occur.

Year 2038 problem is still alive and well | Silent's Blog
https://cookieplmonster.github.io/2022/02/17/year-2038-problem/

UNIX-like OS uses ' UNIX time ', which is expressed as the number of seconds elapsed from 0:00 on January 1, 1970, when handling time information. In the past, UNIX time was stored inside the system in the form of signed 32-bit integers, and had the problem that it could only handle up to 2,147,483,647 seconds. For this reason, there is concern that the system will malfunction at the timing when 2,147,483,647 seconds have passed from 0:00 on January 1, 1970, and since this timing will come in 2038, it is called the 'Year 2038 problem'. It has been called and alerted.

To solve the Year 2038 problem, UNIX time implementations have been changed to signed 64-bit integers on many operating systems. Signed 64-bit integers take 292 billion years to overflow, making it possible to handle all the time humanity needs. Thus, it seemed that engineers no longer had to worry about the Year 2038 problem.

However, one day, Adrian discovered that the following code was posted as a code to convert UNIX time to Windows FILETIME in the article ' Converting a time_t value to a FILETIME ' in Microsoft's document.

[code] #include
#include

void TimetToFileTime (time_t t, LPFILETIME pft)
{
LONGLONG time_value = Int32x32To64 (t, 10000000) + 116444736000000000;
pft-> dwLowDateTime = (DWORD) time_value;
pft-> dwHighDateTime = time_value >> 32;
} [/ code]

Adrian saw this code and was worried about the string 'Int32x32To64', so he investigated it in detail. Then, 'Int32x32To64' was a macro defined by the following code.

[code] # define Int32x32To64 (a, b) ((__int64) (((__ int64) ((long) (a))) * ((long) (b)))) [/ code]

'Int32x32To64' has two inputs, which are first converted to 32 bits, then multiplied by the two inputs and returned in 64 bits. Therefore, if you enter UNIX time in this macro, the overflowed data will be lost when converting to 32 bits, causing the Year 2038 problem again. Adrian made a fix proposal to Microsoft in November 2021 and the documentation was updated immediately.

I thought this would be a solution, but while working on the development of OpenRCT2 , Adrian discovered that the above 'Int32x32To64' code was used. Many engineers have copied the code from Microsoft's documentation, so the problematic code that was once posted has been used in many places.

As far as Adrian investigated, the problematic code was used in the following repository.

O3DE
Dokany
Ceph-Dokan
libarchive
ghc :: filesystem
ImageMagick
Cxbx-Reloaded
ReactOS

Also, regarding the following repository, the code has already been corrected in response to Mr. Adrian's point at the time of writing the article.

OpenRCT2
DuckStation