it-swarm-es.tech

Problema del año 2038

¿Cuál es la probabilidad de que la edición del año 2038 sea muy problemático?

28
8128

Encontré este problema en un sistema Linux integrado que necesitaba manejar fechas posteriores a 2038 en algunos certificados criptográficos a largo plazo, por lo que diría que la similitud de esto depende del dominio de su aplicación.

Si bien la mayoría de los sistemas deberían estar listos mucho antes de 2038, si se encuentra calculando fechas en un futuro lejano, es posible que tenga un problema.

17
Alex B

Creo que este será un problema importante, mucho más pernicioso que los problemas del año 2000 de 1999/2000 porque el código afectado es generalmente de nivel inferior (es CTIME) y, por lo tanto, es más difícil detectar lugares donde se almacena el tiempo de esa manera.

Para complicar aún más las cosas, el hecho de que Y2K fue percibido como un petardo húmedo hará que sea más difícil llamar la atención sobre el problema en el período previo al evento.

Referencias culturales:

Cory Doctorow estaba probando un nuevo modelo para encargar/publicar cuentos bajo licencias abiertas, y yo sugerí un tema de 2038 en uno de ellos, que hizo de manera brillante en Epoch: http://craphound.com/?p = 2337

13
Mark Shuttleworth

Esta es mi opinión, pero este problema se debe a un problema de contador de 32 bits, hoy la mayoría de los sistemas operativos están actualizados para manejar el tiempo en 64 bits (al menos en computadoras de 64 bits), así que supongo que todos los sistemas operativos y el software estarán listos por mucho tiempo. antes de 2038, digamos 2020. Por lo tanto, es posible que solo tenga problemas si en 2038 seguirá ejecutando software a partir de 2020.
Probablemente no sea un problema en casi todos los casos. Espero.

8
radius

Un sistema operativo de 64 bits es, en última instancia, irrelevante para el problema de 2037. (CTIME se agota más cerca de 2037 que de 2038).

La pregunta no es la profundidad de bits del sistema operativo, sino cómo almacena el tiempo el sistema operativo. O cómo elige la columna de la base de datos almacenar el tiempo. O cómo este atributo de sintaxis de tiempo de servicios de directorio almacena el tiempo en el back-end.

Este es un problema mucho mayor de lo que la gente piensa, ya que es muy endémico y común haber usado contadores de tiempo de 32 bits.

Cada instancia que almacena tiempo debe ser revisada y todas las API actualizadas, y también todas las herramientas que lo usan.

Las capas de abstracción que le permiten establecer el tiempo a través de un formato de tiempo legible por humanos, en lugar de los datos sin procesar escritos, lo hacen más fácil, pero ese es solo un caso.

Sospecho que esto va a ser mucho más importante de lo que la mayoría de la gente piensa.

8
geoffc

No es un gran problema.

Durante el primer bombardeo del Y2K, en el que se pidió a los proveedores de software y hardware que certificaran sus productos como "compatibles con Y2K" para poder venderlos (recuerdo que los cables de red de PC Connection estaban certificados como compatibles con Y2K), muchas empresas realizaron auditorías detalladas de todo , configurando relojes en el futuro y probando.

En ese momento, dado que el costo de las pruebas era tan alto, casi siempre probaban con varias fechas, como 1/1/99 (algunos desarrolladores pueden haber usado 99 como un sentinal), 12/31/99, 1/1/00, el salto del 2000, el 19/1/38 y muchos otros. Consulte aquí para obtener una lista tediosa.

Por lo tanto, creo que cualquier software importante que existía en 1999 probablemente no tendrá 2038 errores, pero el software nuevo escrito desde entonces por programadores ignorantes sí. Después de toda la debacle del Y2K, los programadores en general se volvieron mucho más conscientes de los problemas de codificación de fechas, por lo que es poco probable que tenga un impacto tan grande como el Y2K (que, en sí mismo, fue algo anticlímax).

1
Joel Spolsky

Los sistemas de 32 bits que todavía estén funcionando serán un problema.

1
user55149
#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

debería ser 1 en lugar de 9 pero ctime no maneja una fecha más grande:

8 - Sun Jun 13 07:26:08 1141709097

El tiempo de mi sistema (64 bits por supuesto) puede correr incluso 1 millón de años más. La solución es actualizar los sistemas a 64 bits.

El problema es que los programas pueden no manejarlo. Especialmente antiguo, propietario y no mantenido. Los desarrolladores están acostumbrados a seguir los hechos:

  • int son 32 bits (de hecho, se conservan como 32 bits en sistemas de 64 bits, entre otros, porque se asumió que siempre son de 32 bits)
  • La mayoría de los tipos (como time_t) se puede transmitir de forma segura en int

En el popular software FLOSS, ambas cosas probablemente no pasarán por la revisión de "muchos ojos". De los menos populares y propietarios dependerá en gran medida del autor.

Supongo que en el mundo libre * nix el 2038 pasará 'desapercibido' mientras que espero problemas en las plataformas "propietarias" (es decir, aquellas con una gran cantidad de software propietario), especialmente si parte de la parte esencial no se mantendrá.

0
Maciej Piechotka

Si es algo así como el Y2K, algunas personas ya se han visto afectadas y están cambiando el software, pero la mayoría de los desarrolladores lo ignorarán hasta algún momento de la década de 2030, probablemente 2035 más o menos, momento en el que habrá mucho trabajo hecho y cualquier persona con la edad suficiente. conocer K&R C y aún no estar demasiado senil, de repente podrá contratar por mucho dinero. La transición real mostrará muchas cosas que aún no se han hecho, probablemente ninguna tan importante.

0
David Thornley