Are you still using timestamps in your PHP project?

The maximum range of time () is December 13, 1901 20:45:54 to January 19, 2038 03:14:07. There is still 20 years to go. Do I need to use timestamps to write a project at this time? If it has been in the form of Timestamp, by 2038, what is the alternative? The maximum range of time () is December 13, 1901 20:45:54 to January 19, 2038 03:14:07.

There is still 20 years to go. Do I need to use timestamps to write a project at this time?

If it has been in the form of Timestamp, by 2038, what is the alternative?

Reply content:

The maximum range of time () is December 13, 1901 20:45:54 to January 19, 2038 03:14:07.

There is still 20 years to go. Do I need to use timestamps to write a project at this time?

If it has been in the form of Timestamp, by 2038, what is the alternative?

Don't worry. The official PHP version will be upgraded at that time.

This is a system task. At that time, the 32-bit Design reached the upper limit.
It can be 64-bit.
You don't need to worry about it. You certainly won't write code at that time. And, in 20 years, are you sure your project can survive for so long?

References:
Http://stackoverflow.com/questions/5826219/time-after-2038
Http://stackoverflow.com/questions/2012589/php-mysql-year-2038-bug-what-is-it-how-to-solve-it
Https://en.wikipedia.org/wiki/Year_2038_problem

Have you verified your questions and answers before? Php has a 2038bug, just by thinking about it?

~ # Date-s 2040/12/20
Thu Dec 20 00:00:00 CST 2040

~ # Php-r "echo time ();"
2239545608

~ # Php-r "echo date ('ymd His;" time ());
20401220 000015

Of course, if you develop on 32-bit Windows xp, you deserve low.

A serious problem must be pointed out: due to the possibility of processing the future date, it is too late to solve the 2038 problem in a small number of applications, and it must be addressed in advance. For example, Perpetual calendar, timestamp calculation, loan calculation, and other programs.

However, unlike a static type language such as C/C ++/C #/Rust, PHP imposes extremely weak restrictions on Integer types-PHP shaping is only equivalentsigned int, Not supportedunsignedAnd does not support shortening the value range (official documentation ).

Therefore, for the PHP program itself, the timestamp numbers and relatedDateTimeObjects, which can be migrated to 64-bit without modification, thus solving the 2038 problem.

The troublesome part is the database. The general situation is:

• MySQLTIMESTAMPInt32 is used. Therefore, only 2038 is supported.

• The Compatibility Implementation of MySQL is basically the same

• PgSQLtimestampThe underlying storage uses int64, and the upper layer gets an upper limit of 1465001 a.m.

• SQLite does not provide the date type at all. Just save it with bigint.

In short: If you do need to store the timestamp after January 1, 2038 immediately, use BIGINT directly in MySQL.

Is long enough? Php timestamp I remember is not millisecond

I still use timestamp. I don't know what the current requirement is, of course, the current method to meet and implement it.

ISO 8601

Your project is outdated in 20 years, so you don't have to worry about PHP version updates.

This reminds us of the millennium bug problem.

Use the DateTime class for processing.

Think about a project once. I decided that if it was over 2025, the logic behind the project would be invalid. It would be funny if it could not survive for so long.

32-bit MySQL can also use the bigint type to store 64-bit integers. Don't worry, you can use varchar. the timestamp field type is bigint, and the maximum value of 64-bit integer (2 ^ 64)/2-1 = 9223372036854775807 is enough. the server uses 64-bit Linux, and the maximum value of PHP_INT_MAX is (2 ^ 64)/2-1 = 9223372036854775807.

At that time, the Code must be maintained from time to time.

At that time = I do not know whether to write or not to write code ....