Do we have a plan to solve the 2038 problem?

[gclove]

https://dev.mysql.com/doc/refman/8.0/en/datetime.html
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

[netpok]

I believe we shouldn't really plan for it:

• If the Linux kernel was updated to use larger integers, the guys at MySQL should find the time update it in MySQL 15 in the next 18 years.
• On the other hand if they don't the developers should do something about, considering that a laravel project should not go more than 3 years without active maintenance*

*: If it's based on a new LTS, has thorough testing and an automatic composer update solution for security patches (I think there is no way that something does not break though)

[twoloopspl]

I think we should care already about this. Some developers (not me :P ) are still using timestamps to save some time-related things. I've already handled a problem where the user's document expiration date was set to 2039. Changing the timestamp to datetime helped. Personally i would recommend to avoid using timestamps.

[nzkozar]

What benefits does a TIMESTAMP data type have over DATETIME, that Laravel chooses to stay with a lesser range datatype?
Is there an underlying benefit that TIMESTAMP brings to Laravel?

If there is no benefit of TIMESTAMP over DATETIME, continuing to use a potentially problematic data type, is irresponsible.
In addition to being problematic for future compatibility, it also forces developers to use two different datatype for the same data depending on its context.

[shawnlindstrom]

Yes, there is an underlying benefit to TIMESTAMP.

See: 11.2.2 The DATE, DATETIME, and TIMESTAMP Types

"MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)"

If you use DATETIME, you have to store the time zone separately for use in conversions. This is true even though the docs will tell you can store an offset in DATETIME because the offset is relative to whatever the connection time zone is (even though you can, don't use anything other than UTC). The problem becomes apparent if you think about different connections (clients) potentially having different time zones or when considering transitions like Daylight Saving Time.

So, why does Laravel use TIMESTAMP? It's the automatic conversion to and from UTC on the way in and out. When we use TIMESTAMP, we don't have to manage that conversion and store time zone info ourselves.

Hopefully, MySQL will provide a solution in the next decade or so. For now, don't worry about it or, if you're starting fresh, consider Postgres.

[fredbradley]

I'm a little confused. I think all of what @shawnlindstrom says makes sense.. but... we do all have a timezone stored in our Laravel config, it comes with the scaffold!