Preparedness for the Y2K38 problem?

[Vectorial1024]

TL;DR: Y2K38 is a continuation of the long-past Y2K problem; ref https://en.wikipedia.org/wiki/Year_2038_problem

It seems Laravel is not ready for the Y2K38 problem. For example, I noticed the file cache driver stores the "expires at" timestamp as a 10-digit number, which fits inside the 32-bit int range (the Y2K38 problem) but does not fit inside the 64-bit int range (a proposed Y2K38 solution); the 64-bit int will have a string representation length of 19 (2^64 approx = 9223372T).

We should be prepared early. If we could make it past the original Y2K, then we should be able to make it past this upcoming Y2K38 problem.

[Sophist-UK]

1. There is still more than a decade to go.
2. You are assuming that the SQL engines are not going to deliver a fix for this that avoids the need for any PHP changes.

In the words of the great Douglas Adams, and also the great Clive Dunn, "DON'T PANIC!!"

[Vectorial1024]

Read my post again: I did not mention SQL engines. I am talking about the file cache driver having non-compliant timestamp format.

[ahinkle]

I don't think this is a Laravel problem but an industry-wide issue that will be resolved by then.

[Vectorial1024]

Read my post again: I am talking about the Laravel file cache driver having non-compliant timestamp format.

[henzeb]

I think 2034 is early enough. If you still run laravel 11 / 12 by then, you are a joke...