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

22

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

    
pregunta ThePiercingPrince 24.05.2013 - 12:00

4 respuestas

12

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

Esto en caso de que no actualice sus distribuciones actuales hasta que esto suceda. " La actualización es sencilla. Una de estas actualizaciones seguramente incluirá una solución. " como chocobai dijo .

Recuerdo que era el mismo problema / pregunta con máquinas de 16 bits antes de 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 números enteros de time_t de 64 bits. El uso de un valor firmado de 64 bits introduce una nueva fecha envolvente 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 que tm_year usa un valor int firmado de 32 bits que comienza en 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 de los programas de 32 bits que se ejecutan bajo capas de compatibilidad y puede que no resuelvan el problema para programas que almacenan incorrectamente valores de tiempo en variables de tipos distintos de time_t .

Uso Ubuntu 13.04 en 64 bits y, por curiosidad, cambié manualmente el tiempo al 2038-01-19 03:13:00. Después de 03:14:08 no pasó nada:

Entonces, no hay nada que preocuparse por este problema.

Más sobre: ​​

respondido por el Radu Rădeanu 24.05.2013 - 12:45
7

Puede verificar si la hora 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 tu computadora es como la mía, se ajustará de esta manera:

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
    
respondido por el SkylarMT 25.06.2013 - 23:13
3

Escribí y publiqué un breve artículo sobre este tema en 1996. Esto incluyó un breve programa de C para demostrarlo. También tuve correos electrónicos con David Mills sobre problemas similares con NTP, el Network Time Protocol. En mi computadora portátil Ubuntu 14.04 de 64 bits, el código de Perl no presentaba la limitación, por lo que las bibliotecas de 64 bits subyacentes deben haberse modificado.

Sin embargo, la ejecución de mi código de prueba 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, ¡La hora de UNIX se agotará en 2038! ha estado en mi sitio web desde alrededor de 2000. Una variante de esta titulada "Tiempo de UNIX" se publicó en 1998 en "Mejores prácticas del año 2000 para el milenio de computación Y2K" ISBN 0136465064.

    
respondido por el oldunixguy 20.02.2017 - 23:10
2

Linux de 64 bits está listo, al menos si se trata 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 "largo" y "largo" en 64 bits. Linux es de 64 bits.

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

Incluso si hay algún nivel de compatibilidad con versiones anteriores, todos los binarios que quieran obtener el tiempo correcto necesitarán ser reconstruidos para usar las nuevas interfaces de tiempo de 64 bits.

Se ha realizado algún trabajo (consulte, por ejemplo, enlace y enlace ) pero todavía estamos muy lejos de una solución completa. No está claro si habrá o no distribuciones de 32 bits de propósito general que sean seguras para Y2K38.

    
respondido por el Peter Green 27.04.2016 - 00:09

Lea otras preguntas en las etiquetas