¿Cuál es la probabilidad de que el tema del año 2038 sea muy problemático?
Respuestas:
He encontrado este problema en un sistema Linux incorporado 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 hoy te encuentras calculando fechas en el futuro, es posible que tengas un problema.
mktimellamada estaba fallando silenciosamente.
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 generalmente es 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 se percibiera que Y2K era un squib 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 la puesta en marcha / publicación de historias cortas bajo licencias abiertas, y le sugerí un tema de 2038 para uno de ellos, lo que hizo brillantemente en Época: http://craphound.com/?p=2337
Hace unos años, ya había informes de problemas, en áreas como programas hipotecarios que hacen cálculos de préstamos a 30 años: 2008 + 30 = 2038.
Un sistema operativo de 64 bits es irrelevante para el problema 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 tiempo? ¿O cómo este directorio mantiene el tiempo de almacenamiento del atributo de sintaxis de tiempo en el back-end?
Este es un problema mucho más grande de lo que la gente piensa, ya que es tan endémico y común haber usado contadores de tiempo de 32 bits.
Cada instancia que almacena tiempo necesita ser revisada, y todas las API actualizadas, y todas las herramientas que lo usan actualizadas también.
Las capas de abstracción que le permiten establecer la hora a través de un formato de hora legible por el ser humano, en lugar de los datos en bruto escritos lo hacen más fácil, pero ese es solo un caso.
Sospecho que esto va a ser mucho más grande de lo que la mayoría de la gente piensa.
time_ten absoluto. Almacena año, mes y día como campos en un valor de 16 bits: 5 bits por día, 4 por mes, dejando 7 por año. 2107 es 1980 (año cero en tierra FAT) + 2 ^ 7-1. Para mayor diversión, FAT almacena la hora del día de la misma manera en otro valor de 16 bits, pero si hace los cálculos, encontrará que necesita 17 bits para almacenar la hora del día de esta manera. FAT evita esto dejando caer un bit de resolución por segundos; FAT no puede distinguir los cambios con menos de 2 segundos de diferencia. ¡Ah, Microsoft, qué mundo tan aburrido sería sin tus innecesarias incompatibilidades!
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 se actualizan para manejar el tiempo en 64 bits (al menos en computadoras de 64 bits), por lo que supongo que todo el sistema operativo 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.
Durante el primer bombardeo de Y2K, en el que se exigió a los proveedores de software y hardware que certificaran sus productos como "compatibles con Y2K" para poder venderlos (recuerdo que los cables de red en 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 sentinal), 31/12/99, 1/1 / 00, el salto de 2000, 19/1/38, y muchos otros. Vea aquí para una lista tediosa.
Por lo tanto, creo que cualquier software importante que existiera en 1999 probablemente no tendrá 2038 errores, pero sí los nuevos programas escritos desde entonces por programadores ignorantes. Después de toda la debacle de Y2K, los programadores generalmente se hicieron 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 de Y2K (que, en sí mismo, fue algo anticlímax).
Los sistemas de 32 bits que todavía se ejecutan para entonces serán un problema
#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 funcionar 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, propiedad y no mantenido. Los desarrolladores están acostumbrados a los siguientes hechos:
intson de 32 bits (de hecho, se conservan como 32 bits en sistemas de 64 bits, entre otros porque se suponía que siempre son de 32 bits)time_t) se pueden usar de forma seguraintEn el popular software FLOSS, ambas cosas probablemente no pasarán por la revisión de 'muchos ojos'. En menos popular y propietario dependerá en gran medida del autor.
Supongo que en el mundo libre * nix, el 2038 pasará desapercibido mientras espero problemas en las plataformas "propietarias" (es decir, aquellas con gran cantidad de software propietario), especialmente si parte de la parte crutial no se mantendrá.
time_t(o equivalente) en el sistema operativo de 32 bits tiene 32 bits, mientras que time_t(o equivalente) en el sistema operativo de 64 bits tiene 64 bits. Pensé que era lo suficientemente claro, aunque con cierta simplificación.
Si se parece a 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 en la década de 2030, probablemente en 2035, momento en el que habrá mucho trabajo hecho, y cualquiera con la edad suficiente saber K&R C y aún no 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.
El problema del año 2000 fueron dos cartas que representaban el año en lugar de cuatro.
Muchos sistemas no tenían forma de distinguir entre 2000 y 1900, ya que solo almacenaban el '00'.
Casi todos los sistemas ahora usan 4 caracteres para almacenar el año, o usan una biblioteca de algún tipo.
Entonces, preocupémonos por el año 10000 (Y10K). Excepto por los escritores del sistema operativo y de la biblioteca ...