LC Date Conversions post 2035

[Martin Koob]

Hi

This thread reminded me of some sci-fi show show I was watching which referenced the collapse of society on earth caused by a bug around 2035 or something like that where the computers could not process dates beyond that.   I thought this is just a off hand reference to something Y2K. 

But I did a quick search turned up this:

https://en.wikipedia.org/wiki/Year_2038_problem

So a signed 32 bit number counting the seconds since Jan 1, 1970 will overflow after 03:14:07 UTC <https://en.wikipedia.org/wiki/Coordinated_Universal_Time> on 19 January 2038.

So if it was in referencing  that date and time in 2038 that your problem showed up then maybe that was the cause.  But that would not explain it if the date things started going wrong was in 2035.

But it appears from the tests that Andreas did on Windows 10 and MacOS 12.6 that they have already resolved the Year 2038 problem.

Maybe the MacOS is using a 64 bit number now for the Unix time.  According to wikipedia

"though many modern systems have been upgraded to measure Unix time with signed 64-bit <https://en.wikipedia.org/wiki/64-bit_computing> integers which will not overflow for 292 billion years.”

Not sure what Window is doing that it is only going to work till 3000.  Maybe MicroSoft have decided to EOL Windows  then and have plans to release a totally rewritten operating system then.


Martin


> On Nov 7, 2022, at 2:49 AM, Andreas Bergendal via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> But how far does the 4-digit conversion work? Here’s what I’ve found:
> - On Windows 10, it works until year 3000, and stops working on year 3001 (it just returns the input without converting).
> - On MacOS 12.6 it works at least until year 2.100.000.000 (which is a Sunday… :). By that time we should be expecting LC v14 or something, or maybe that LC rules the galaxy, so I hope that’s sorted by then… :D