Are you still using timestamps in your PHP project?

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

There are still 20 years, time to write the project also to use the timestamp?

If you have been using the timestamp form for 2038 years, what are the alternatives?

Reply content:

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

There are still 20 years, time to write the project also to use the timestamp?

If you have been using the timestamp form for 2038 years, what are the alternatives?

No need to worry, then the official will upgrade the PHP version to resolve

This is the system, is the design of the 32 bit reached the upper limit.
can use 64 bits.
You may not have to, anyway, you will not write code anymore, and, 20 time, you are sure that your project can live that long?

Resources:
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 done any verification before asking and answering? It's just a matter of thinking in the brain. PHP 2038bug?

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

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

~# Php-r "echo date (' Ymd his;" Time ());
20401220 000015

Of course, you're developing on 32-bit Windows XP, and you deserve low.

A serious problem must be pointed out: since it is possible to deal with future dates, the 2038 problem is too late to resolve in a few applications and must be addressed in advance. For example: Perpetual calendar, time stamp calculation, loan calculation and other procedures.

However, unlike static type languages such as C/c++/c#/rust, PHP has a very weak type qualification of--php, which is only equivalent to the platform signed int , does not support unsigned , and does not support shortening the range of values (official documents).

So for the PHP program itself, timestamp numbers and related DateTime objects can be migrated without modification to 64 bits to solve the 2038 problem.

The trouble is the database section. The current general situation is:

• MySQL TIMESTAMP uses Int32, so it only supports up to 2038

• MySQL's various compatible implementations basically have the same problem

• Pgsql's timestamp Underlying storage uses int64, upper card an ad 1465001 upper limit value

• SQLite does not provide a date type, you can save it with bigint.

In short: If you do have a need to store timestamps immediately after 2038, use bigint directly in MySQL.

Is long enough? PHP Timestamp I remember there was no millisecond part of the

I'm still using the timestamp. I don't know what the immediate demand is, of course, the immediate way to meet and realize

ISO 8601

20 your project is a cliché, so don't worry about the PHP update.

Reminds us of the millennium bug problem.

Please use the DateTime class to handle

Think of a project once, I judge if more than 2025 years, the back of the logic will expire, anyway, the project will not live so long, it is funny.

32-bit MySQL can also use the bigint type to store 64-bit integers, or you can use varchar. timestamp field type with bigint,64 bit integer maximum (2^64)/2-1= 9223372036854775807 is enough. Server with 64-bit Linux, at this time the maximum value of Php_int_max is also (2^64)/2-1=9223372036854775807.

At that time the code must have been maintained by me, aha haha

At that time = = I do not know also write not write code ....

