Unix Time

[John]

POSIX or "Unix time" is the number of seconds since UTC January 1, 1970, not counting leap seconds. The signed 32 bit implementation of the POSIX time system, used in Unix systems and embedded in countless applications, will overflow on 2038-01-19T3:14:08Z.

Humm, Should I care?

[AIR]

POSIX or "Unix time" is the number of seconds since UTC January 1, 1970, not counting leap seconds. The signed 32 bit implementation of the POSIX time system, used in Unix systems and embedded in countless applications, will overflow on 2038-01-19T3:14:08Z.

Humm, Should I care?

In 2038, it will incapacitate our AI overlords,  and reset time itself to pre Global Warming days...hmm, maybe the SyFy Network should do an anthology series based on time resetting but people keeping their 2038 knowledge.....

[John]

Code: ScriptBasic

1. PRINT TIMEVALUE(2050,1,1),"\n"
2.  

(0): error &H31:The time is not valid, cannot be earlier than January 1, 1970. 00:00

It could be a problem for apps doing mortgages.

TIMEVALUE(), GMTIME and NOW are the only functions that come to mind that would break.

[John]

Linux uses a 64-bit time_t for 64-bit architectures only; the pure 32-bit ABI is not changed due to backward compatibility. There is ongoing work, mostly for embedded Linux systems, to support 64-bit time_t on 32-bit architectures, too.

The x32 ABI for Linux (which defines an environment for programs with 32-bit addresses but running the processor in 64-bit mode) uses a 64-bit time_t. Since it was a new environment, there was no need for special compatibility precautions.

AIR,

What is your guess it would take to use 64-bit time_t in SB?

[John]

My advice how to fix this is when 2038 rolls around, a new start date of January 1st 2000 would be used instead of January 1st 1970. This gives the 32 bit time_t a few more years.