¿Qué debemos hacer para prepararnos para 2038?

Question

Me gustaría pensar que parte del software que estoy escribiendo hoy se utilizará dentro de 30 años.Pero también soy consciente de que gran parte de esto se basa en la tradición UNIX de exponer el tiempo como el número de segundos desde 1970.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

La ejecución da como resultado:

• Jueves 1 de enero 00:00:00 1970
• Sábado 30 de agosto 18:37:08 2008
• Mar 19 de enero 03:14:07 2038
• Viernes 13 de diciembre 20:45:52 1901

Las funciones ctime(), gmtime() y localtime() toman como argumento un valor de tiempo que representa el tiempo en segundos desde la Época (00:00:00 UTC, 1 de enero de 1970;ver tiempo(3) ).

Me pregunto si hay algo proactivo que hacer en esta área como programador, o ¿debemos confiar en que todos los sistemas de software (también conocidos como sistemas operativos) se actualizarán mágicamente de alguna manera en el futuro?

Actualizar Parecería que, efectivamente, los sistemas de 64 bits están a salvo de esto:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• Miércoles 31 de diciembre 16:00:00 PST 1969
• Sábado 30 de agosto 12:02:40 PDT 2008
• Sábado 16 de agosto 23:12:55 PST 292278994
• domingo 02 de diciembre 08:47:04 PST 292269055

Pero ¿qué pasa con el año 292278994?

Answer 1

He escrito un reemplazo portátil para time.h (actualmente solo localtime(), gmtime(), mktime() y timegm()) que usa tiempo de 64 bits incluso en máquinas de 32 bits.Está pensado para incluirse en proyectos C como reemplazo de time.h.Se está utilizando en Perl y también tengo la intención de solucionar los problemas de 2038 de Ruby y Python.Esto le da un rango seguro de +/- 292 millones de años.

Puedes encontrar el código. en el proyecto y2038.No dude en publicar cualquier pregunta en el rastreador de problemas.

En cuanto a "esto no será un problema hasta dentro de 29 años", lea esto lista de respuestas estándar a ese.En resumen, cosas suceden en el futuro y a veces es necesario saber cuándo.tambien tengo una presentación sobre el problema, lo que no es una solución y lo que sí lo es..

Ah, y no olvide que muchos sistemas horarios no manejan fechas anteriores a 1970.Cosas que sucedieron antes de 1970, a veces es necesario saber cuándo.

Answer 2

Siempre puedes implementar RFC 2550 y estar a salvo para siempre ;-)

El universo conocido tiene un pasado y un futuro finitos.La edad actual del universo se estima en [Zebu] entre 10 ** 10 y 2 * 10 ** 10 años.La muerte del universo se estima en [Nigel] que ocurre en 10 ** 11 años y en [Drake] como en 10 ** 12 años para un universo cerrado (el gran crujido) o 10 ** 14 años para Un universo abierto (la muerte de calor del universo).

 

Los programas compatibles con Y10K pueden optar por limitar el rango de fechas que apoyan a aquellos consistentes con la vida esperada del universo.Los sistemas compatibles con Y10K deben aceptar fechas de Y10K de 10 ** 12 años en el pasado a 10 ** 20 años en el futuro.Los sistemas compatibles con Y10k deberían aceptar fechas para al menos 10 ** 29 años en el pasado y el futuro.

Answer 3

Visual Studio pasó a una representación de 64 bits de time_t en Visual Studio 2005 (sin dejar _time32_t por compatibilidad con versiones anteriores).

Siempre que tenga cuidado de escribir siempre el código en términos de time_t y no asuma nada sobre el tamaño, como señala sysrqb, su compilador resolverá el problema.

Answer 4

Creo que deberíamos dejar el error.Luego, alrededor de 2036, podremos empezar a vender consultoría por grandes sumas de dinero para probarlo todo.Después de todo, ¿no es así como gestionamos con éxito la renovación del período 1999-2000?

¡Solo bromeo!

Estaba sentado en un banco en Londres en 1999 y quedé bastante sorprendido cuando vi a un consultor comenzar a probar la máquina de café con el Y2K.Creo que si aprendimos algo de ese fiasco, es que la gran mayoría del software simplemente funcionará y la mayor parte del resto no se derretirá si falla y puede repararse después del evento si es necesario.Como tal, no tomaría ninguna precaución especial hasta mucho más cerca del momento.

Answer 5

Dada mi edad, creo que debería aportar mucho a mi pensión y pagar todos mis departamentos, ¡así que alguien más tendrá que adaptarse al software!

Lo sentimos, si piensa en el “valor actual neto” de cualquier software que escriba hoy, no tendrá ningún efecto en lo que hará el software en 2038.Un “retorno de la inversión” de más de unos pocos años es poco común para cualquier proyecto de software, por lo que usted gana mucho más dinero para su empleador enviando el software más rápido, en lugar de pensar con tanta anticipación.

La única excepción común es el software que tiene que predecir el futuro; el año 2038 ya es un problema para los sistemas de cotización de hipotecas.

Answer 6

Mantenga buena documentación e incluya una descripción de sus dependencias de tiempo.No creo que mucha gente haya pensado en lo difícil que podría ser esta transición; por ejemplo, las cookies HTTP se interrumpirán en esa fecha.

Answer 7

¿Qué debemos hacer para prepararnos para 2038?

Escóndete, porque se acerca el apocalipsis.

Pero en serio, espero que los compiladores (o las personas que los escriben, para ser precisos) puedan manejar esto.Tienen casi 30 años.Espero que sea suficiente tiempo.

¿En qué momento empezamos a prepararnos para el año 10.000?¿Algún fabricante de hardware o laboratorio de investigación ha investigado la forma más fácil de pasar a cualquier nueva tecnología que tengamos que tener a causa de ello?

Answer 8

Trabajo en forma integrada y pensé en publicar nuestra solución aquí.Nuestros sistemas son de 32 bits y lo que vendemos ahora tiene una garantía de 30 años, lo que significa que se encontrarán con el error del año 2038.Actualizar en el futuro no era una solución.

Para solucionar este problema, configuramos la fecha del kernel 28 años antes que la fecha actual.No es un desplazamiento aleatorio, 28 años es exactamente el tiempo que tardarán los días de la semana en volver a coincidir.Por ejemplo, estoy escribiendo esto un jueves y la próxima vez que el 7 de marzo sea jueves será dentro de 28 años.

Además, todas las aplicaciones que interactúan con fechas en nuestros sistemas tomarán la fecha del sistema (time_t), la convertirán a una hora personalizada64_t y aplicarán el desplazamiento de 28 años a la fecha correcta.

Creamos una biblioteca personalizada para manejar esto.El código que estamos usando se basa en esto: https://github.com/android/platform_bionic

Así, con esta solución podrás conseguir fácilmente 28 años más.

Answer 9

Para 2038, todas las bibliotecas de tiempo deberían usar enteros de 64 bits, por lo que esto no será un gran problema (en software que no esté completamente sin mantenimiento).

Sin embargo, los programas COBOL pueden ser divertidos.

Answer 10

La palabra operativa es "debería".

Si necesita asegurarse de que esté preparado para el futuro, puede crear su propia clase de fecha/hora y usarla, pero yo solo lo haría si cree que lo que escriba se usará en el sistema operativo heredado.