03:14:07 UTC on Tuesday, 19 January 2038

[sje]

03:14:07 UTC on Tuesday, 19 January 2038 is the end of the 32 bit delineated Unix time epoch.

Does your program sample the current time in any form?

What happens if you were to set your system time and date to the above end-of-epoch? (Yes, you'll have to turn off external synchronization, or just disconnect from the network.)

Tempus fugit

[geots]

03:14:07 UTC on Tuesday, 19 January 2038 is the end of the 32 bit delineated Unix time epoch.

Does your program sample the current time in any form?

What happens if you were to set your system time and date to the above end-of-epoch? (Yes, you'll have to turn off external synchronization, or just disconnect from the network.)

Tempus fugit

I can't write one-fourth of a line of programming, but I could not resist replying here. If at that point in time I am still alive, I can promise you chess as well as computers would be the last thing on my mind. That is one of those- "throw it up into the wind and let the dust settle it" deals.


gts

[sje]

If one has followed good programming practices with respect to type safety, then a fresh re-compilation for a 64 bit Unix target should be sufficient.

Any likely problems arise due to external representation of Unix time_t type objects or with assumption that a time_t object can fin into a 32 bit word. Some of these deficiencies may not appear in the chess software, but perhaps in a supporting application or library (e.g., an SQL database).

The use of old, 32 bit time_t filesystem structure components is fundamentally incompatible with post-2038 code.