PHP y mySQL: año 2038 Error: ¿Qué es? ¿Cómo resolverlo?

Estaba pensando en usar TIMESTAMP para almacenar la fecha y la hora, pero leí que hay una limitación del año 2038. En lugar de hacer mi pregunta a granel, preferí dividirla en partes pequeñas para que también sea fácil de entender para los usuarios novatos. Entonces mi pregunta (s):

1. ¿Cuál es exactamente el problema del año 2038?
2. ¿Por qué ocurre y qué sucede cuando ocurre?
3. ¿Como lo resolvemos?
4. ¿Existen posibles alternativas a su uso que no planteen un problema similar?
5. ¿Qué podemos hacer con las aplicaciones existentes que usan TIMESTAMP, para evitar el llamado problema, cuando realmente ocurre?

Gracias por adelantado.

He marcado esto como un wiki de la comunidad, así que siéntete libre de editarlo cuando quieras.

¿Cuál es exactamente el problema del año 2038?

"El problema del año 2038 (también conocido como Unix Millennium Bug, Y2K38 por analogía con el problema Y2K) puede hacer que algunos programas de computadora fallen antes o en el año 2038. El problema afecta a todos los programas y sistemas que almacenan la hora del sistema como un 32 -bit entero e interprete este número como el número de segundos desde las 00:00:00 UTC del 1 de enero de 1970 ".

¿Por qué ocurre y qué sucede cuando ocurre?

Las horas posteriores a las 03:14:07 UTC del martes 19 de enero de 2038 se 'envolverán' y se almacenarán internamente como un número negativo, que estos sistemas interpretarán como una hora del 13 de diciembre de 1901 en lugar de 2038. Esto se debe a el hecho de que el número de segundos desde la época de UNIX (1 de enero de 1970 00:00:00 GMT) habrá excedido el valor máximo de una computadora para un entero de 32 bits con signo.

¿Como lo resolvemos?

• Utilice tipos de datos largos (64 bits es suficiente)
• Para MySQL (o MariaDB), si no necesita la información de tiempo, considere usar el DATEtipo de columna. Si necesita una mayor precisión, utilice en DATETIMElugar de TIMESTAMP. Tenga en cuenta que las DATETIMEcolumnas no almacenan información sobre la zona horaria, por lo que su aplicación tendrá que saber qué zona horaria se utilizó.
• Otras posibles soluciones descritas en Wikipedia
• Espere a que los desarrolladores de MySQL solucionen este error informado hace más de una década.

¿Existen posibles alternativas a su uso que no planteen un problema similar?

Intente siempre que sea posible utilizar tipos grandes para almacenar fechas en bases de datos: 64 bits es suficiente: un tipo largo y largo en GNU C y POSIX / SuS, o sprintf('%u'...)en PHP o la extensión BCmath.

¿Cuáles son algunos casos de uso potencialmente innovadores aunque todavía no estemos en 2038?

Entonces, un DATETIME de MySQL tiene un rango de 1000-9999, pero TIMESTAMP solo tiene un rango de 1970-2038. Si su sistema almacena fechas de nacimiento, fechas futuras (por ejemplo, hipotecas a 30 años) o similares, ya se encontrará con este error. Nuevamente, no use TIMESTAMP si esto va a ser un problema.

¿Qué podemos hacer con las aplicaciones existentes que usan TIMESTAMP, para evitar el llamado problema, cuando realmente ocurre?

Pocas aplicaciones PHP seguirán existiendo en 2038, aunque es difícil prever ya que la web no es una plataforma heredada todavía.

Aquí es un proceso para modificar una columna de tabla de base de datos para convertir TIMESTAMPa DATETIME. Comienza con la creación de una columna temporal:

# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;

# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;

# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);

# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`

Recursos

• Problema del año 2038 (Wikipedia)
• Internet terminará en 30 años

Cuando usa UNIX Timestamps para almacenar fechas, en realidad está usando un entero de 32 bits, que mantiene la cuenta del número de segundos desde 1970-01-01; ver hora de Unix

Ese número de 32 bits se desbordará en 2038. Ese es el problema de 2038.

Para resolver ese problema, no debe usar una marca de tiempo UNIX de 32 bits para almacenar sus fechas, lo que significa que cuando use MySQL, no debe usar TIMESTAMP, pero DATETIME(consulte 10.3.1. Los tipos DATETIME, DATE y TIMESTAMP ):

El DATETIMEtipo se utiliza cuando necesita valores que contienen información de fecha y hora. El rango admitido es '1000-01-01 00:00:00'a '9999-12-31 23:59:59'.

El TIMESTAMPtipo de datos tiene un rango de '1970-01-01 00:00:01'UTC a '2038-01-19 03:14:07'UTC.

Lo mejor (probablemente) que puede hacer con su aplicación para evitar / solucionar ese problema es no usar TIMESTAMP, pero DATETIMEpara las columnas que deben contener fechas que no estén entre 1970 y 2038.

Sin embargo, una pequeña nota: es muy probable (estadísticamente hablando) que su aplicación haya sido reescrita un par de veces antes de 2038 ^^ Así que tal vez, si no tiene que lidiar con fechas en el futuro , no tendrá que ocuparse de ese problema con la versión actual de su aplicación ...

Una búsqueda rápida en Google hará el truco: problema del año 2038

1. El problema del año 2038 (también conocido como Unix Millennium Bug, Y2K38 por analogía con el problema Y2K) puede hacer que algunos programas de computadora fallen antes o en el año 2038
2. El problema afecta a todo el software y los sistemas que almacenan la hora del sistema como un entero de 32 bits con signo e interpretan este número como el número de segundos desde las 00:00:00 UTC del 1 de enero de 1970. La última hora que se puede representar de esta manera son las 03:14:07 UTC del martes 19 de enero de 2038. Los tiempos posteriores a este momento se "envolverán" y se almacenarán internamente como un número negativo, que estos sistemas interpretarán como una fecha de 1901 en lugar de 2038
3. No hay una solución fácil para este problema para las combinaciones de CPU / SO existentes, sistemas de archivos existentes o formatos de datos binarios existentes.

http://en.wikipedia.org/wiki/Year_2038_problem tiene la mayoría de los detalles

En resumen:

1) + 2) El problema es que muchos sistemas almacenan la información de fecha como un int de 32 bits con signo igual al número de segundos desde el 1/1/1970. La última fecha que se puede almacenar de esta manera es a las 03:14:07 UTC del martes 19 de enero de 2038. Cuando esto suceda, el int "se ajustará" y se almacenará como un número negativo que se interpretará como una fecha de 1901. Lo que sucederá exactamente entonces varía de un sistema a otro, pero basta con decir que probablemente no sea bueno para ninguno de ellos.

Para los sistemas que solo almacenan fechas en el pasado, ¡supongo que no necesita preocuparse por un tiempo! El principal problema son los sistemas que funcionan con fechas en el futuro. Si su sistema necesita funcionar con fechas de 28 años en el futuro, ¡debería empezar a preocuparse ahora!

3) Utilice uno de los formatos de fecha alternativos disponibles o cambie a un sistema de 64 bits y utilice entradas de 64 bits. O para bases de datos, use un formato de marca de tiempo alternativo (por ejemplo, para MySQL use DATETIME)

4) ¡Ver 3!

5) Ver 4 !!! ;)

Hermanos, si necesita usar PHP para mostrar marcas de tiempo, esta es la MEJOR solución PHP sin cambiar el formato UNIX_TIMESTAMP.

Utilice una función custom_date (). Dentro de él, use el DateTime. Aquí está la solución DateTime .

Siempre que tenga SIN FIRMAR BIGINT (8) como marcas de tiempo en la base de datos. Siempre que tenga PHP 5.2.0 ++

Como no quería actualizar nada, le pedí a mi backend (MSSQL) que hiciera este trabajo en lugar de PHP.

$qry = "select DATEADD(month, 1, :date) next_date ";
$rs_tmp = $pdo->prepare($qry);
$rs_tmp->bindValue(":date", '2038/01/15');
$rs_tmp->execute();
$row_tmp = $rs_tmp->fetch(PDO::FETCH_ASSOC);

echo $row_tmp['next_date'];

Puede que no sea una forma eficiente, pero funciona.