¿Fallará el reloj de Linux el 19 de enero de 2038 3:14:08?

Estoy un poco preocupado por esto. Se llama el "problema del año 2038". ¿El kernel de Linux o Ubuntu está listo para manejar fechas posteriores a esta fecha, a partir de 12.04?

No, no fallará. En el peor de los casos, desde el punto de vista de un programador, funcionará como se esperaba: se restablecerá hasta la fecha 1901-12-13 20:45:52:

Esto en caso de que no actualice sus distribuciones actuales hasta que esto suceda. " Actualizar es fácil. Una de estas actualizaciones seguramente contendrá una solución ", como dijo Chocobai .

Recuerdo que era el mismo problema / pregunta con las máquinas de 16 bits antes del 2000 y al final no hubo ningún problema.

Una solución de Wikipedia:

La mayoría de los sistemas operativos diseñados para ejecutarse en hardware de 64 bits ya usan time_tenteros de 64 bits con signo . El uso de un valor firmado de 64 bits introduce una nueva fecha de ajuste que es más de veinte veces mayor que la edad estimada del universo: aproximadamente 292 mil millones de años a partir de ahora, a las 15:30:08 del domingo 4 de diciembre de 292,277,026,596. La capacidad de realizar cálculos en fechas está limitada por el hecho de quetm_yearutiliza un valor int de 32 bits con signo a partir de 1900 para el año. Esto limita el año a un máximo de 2,147,485,547 (2,147,483,647 + 1900). Si bien esto resuelve el problema para ejecutar programas, no resuelve el problema de almacenar valores de fecha en archivos de datos binarios, muchos de los cuales emplean formatos de almacenamiento rígidos. Tampoco resuelve el problema para programas de 32 bits que se ejecutan bajo capas de compatibilidad y puede que no resuelva el problema para programas que almacenan incorrectamente valores de tiempo en variables de tipos distintos time_t.

Uso Ubuntu 13.04 en 64 bits y, por curiosidad, cambié manualmente la hora a 2038-01-19 03:13:00. Después de las 03:14:08 no había pasado nada:

Por lo tanto, no hay nada de qué preocuparse por este problema.

Más sobre:

• Problema del año 2038 - Wikipedia .
• Fin del Tiempo (Unix) - Numberphile .

Puede verificar si el tiempo de su computadora se bloqueará utilizando el siguiente script de Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Si su computadora estará bien, obtendrá esto:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Si su computadora es como la mía, se ajustará así:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

También podría hacer esto:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

Escribí y publiqué un breve artículo sobre esto en 1996. Esto incluyó un breve programa en C para demostrarlo. También recibí correos electrónicos con David Mills sobre problemas similares con NTP, el Protocolo de tiempo de red. En mi computadora portátil Ubuntu 14.04 de 64 bits, el código perl no exhibía la limitación, por lo que las bibliotecas subyacentes de 64 bits deben haberse modificado.

Sin embargo, ejecutar mi código de prueba de hace mucho tiempo muestra el tiempo de vuelta a la época de UNIX. Entonces, no todo está bien con el código de 32 bits del pasado.

Mi artículo de 1996, ¡ El tiempo de UNIX se acabará en 2038! ha estado en mi sitio web desde alrededor del año 2000. Una variante de este titulada "Tiempo UNIX" se publicó en 1998 en "Las mejores prácticas del año 2000 para la informática del milenio Y2K" ISBN 0136465064.

Linux de 64 bits está listo, al menos si está hablando de las interfaces principales del sistema operativo (las aplicaciones individuales, por supuesto, todavía pueden arruinarlo). time_t se define tradicionalmente como un alias para "long" y "long" en linux de 64 bits que es de 64 bits.

La situación para Linux de 32 bits (y la capa de compatibilidad para binarios de 32 bits en Linux de 64 bits) es mucho menos optimista. Está roto y arreglarlo sin romper todos los archivos binarios existentes no es una tarea fácil. Una gran cantidad de API usa time_t y, en muchos casos, está incrustado como parte de las estructuras de datos, por lo que no solo las API deben duplicarse, sino que también las estructuras de datos con las que trabajan.

Incluso si hay algún nivel de compatibilidad con versiones anteriores, será necesario reconstruir todos los binarios que deseen obtener la hora correcta para utilizar las nuevas interfaces de tiempo de 64 bits.

Se ha realizado algún trabajo (ver, por ejemplo, https://lwn.net/Articles/643234/ y http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) pero cometemos todavía están muy lejos de una solución completa. No está claro si alguna vez habrá distribuciones de 32 bits de uso general que sean seguras para Y2K38.