2038 Unix Time problem

Summary

The current Unix Time epoch will roll over on the morning of January 19, 2038. Any program that depends upon accurate date/time values that uses 32-bit values will be affected by this problem. Even using 64-bit operating systems or tools will not alleviate the problem if 32-bit time values are being used. Yes, I know this won't happen for a little less than 13 years, but this is the new equivalent of the 6-digit date problem of 2000, but if people had not been thinking about that in 1987 - which, by the way, I was - things might not have gone so smoothly. Taking steps to remediate this problem now gives ample time to make sure it is done long before it blows up into a full-blown crisis.

System Information

• Operating system:

  Any providing Unix Time using 32-bit values

• Processor architecture:

  All

• Compiler version:

  Any that has not had full regression testing to confirm the Run-time library is switching over to 64-bit values or has been validated as not being affected.

• Device:

Steps to reproduce

Reset the system clock to some time in February, 2038 and see if the compiler will compile itself or test programs correctly and that the prograns do work.

Example Project

What is the current bug behavior?

Status is unknown since the level of use of time or date values that depend on 32-bit values in the compiler or run-time libraries is not easily determined.

What is the expected (correct) behavior?

That dates/times show correct, positive values.

Relevant logs and/or screenshots

Possible fixes

Make sure date/time fields in compiler, run-time system, and any utilities or packages included with Free Pascal that use date or time values are fully 64-bit compliant and that the time request is a 64-bit sized request. Also update the documentation once this issue has been remediated to let people know about it and know that you did something to fix it.