unix - ¿Qué deberíamos hacer para prepararnos para 2038?
time maintainability (10)
Me gustaría pensar que parte del software que estoy escribiendo hoy se usará en 30 años. Pero también soy consciente de que gran parte de ella se basa en la tradición de 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);
}
Resultados de ejecución en:
- Jue 1 de enero 00:00:00 1970
- Sáb 30 de agosto 18:37:08 2008
- Martes 19 de enero 03:14:07 2038
- Vie 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) de alguna manera serán mejorados mágicamente en el futuro.
Actualización Parece que de hecho 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é 31 de diciembre a las 16:00:00 PST 1969
- Sáb 30 de agosto 12:02:40 PDT 2008
- Sáb 16 ago 23:12:55 PST 292278994
- Dom 02 de diciembre 08:47:04 PST 292269055
Pero, ¿qué hay del año 292278994?
¿Qué deberíamos hacer para prepararnos para 2038?
Ocultar, porque el apocalipsis está por venir.
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é punto comenzamos a prepararnos para Y10K? ¿Han visto los fabricantes de hardware / laboratorios de investigación la forma más fácil de pasar a la nueva tecnología que tendremos que tener debido a eso?
Creo que deberíamos dejar el error. Entonces alrededor de 2036 podemos comenzar a vender asesoría para grandes sumas de dinero para probar todo. Después de todo, no es así cómo logramos con éxito la renovación de 1999-2000.
¡Solo bromeo!
Estuve sentado en un banco en Londres en 1999 y quedé bastante sorprendido cuando vi a un consultor comenzar el Y2K probando la máquina de café. Creo que si aprendimos algo de ese fiasco, fue que la gran mayoría del software simplemente funcionará y la mayoría del resto no causará una fusión si falla y se puede arreglar después del evento si es necesario. Como tal, no tomaría ninguna precaución especial hasta mucho más cerca del momento.
Dado mi edad, creo que debería pagar mucho en mi pensión y pagar todos mis depósitos, ¡así que alguien más tendrá que adaptarse al software!
Lo sentimos, si piensas en el "valor actual neto" de cualquier software que escribas hoy, no tiene efecto lo que el software hace en 2038. Un "retorno de inversión" de más de unos pocos años es poco común para cualquier proyecto de software, por lo usted gana mucho más dinero para su empleador al enviar el software más rápido, en lugar de pensar en el futuro.
La única excepción común es el software que tiene que predecir el futuro, 2038 ya es un problema para los sistemas de cotización de hipotecas.
He escrito un reemplazo portátil para time.h (actualmente solo localtime (), gmtime (), mktime () y timegm ()) que usa 64 bit time incluso en máquinas de 32 bit. Se pretende incluir en los proyectos C como un reemplazo de time.h. Se está utilizando en Perl y también tengo la intención de solucionar los problemas 2038 de Ruby y Python. Esto le proporciona un rango seguro de +/- 292 millones de años.
Puede encontrar el código en el proyecto y2038 . Por favor, siéntase libre de publicar cualquier pregunta al rastreador de problemas .
En cuanto a "esto no va a ser un problema por otros 29 años", lea detenidamente esta lista de respuestas estándar . En resumen, las cosas suceden en el futuro y a veces es necesario saber cuándo. También tengo una presentación sobre el problema, qué no es una solución y qué es .
Ah, y no olvide que muchos sistemas de tiempo no manejan fechas anteriores a 1970. Las cosas sucedieron antes de 1970, a veces es necesario saber cuándo.
La palabra operativa es "debería".
Si necesita garantizar la futura protección, puede construir su propia clase de fecha / hora y usarla, pero solo lo haría si considera que lo que escribe se utilizará en el sistema operativo heredado.
Mantenga una buena documentación e incluya una descripción de las dependencias de su 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 romperán en esa fecha.
Para el año 2038, las bibliotecas de tiempo deberían estar usando números enteros de 64 bits, por lo que no será tan difícil (en software que no está completamente sin mantenimiento).
Los programas de COBOL pueden ser divertidos.
Siempre puede implementar RFC 2550 y estar seguro para siempre ;-)
El universo conocido tiene un pasado y un futuro finitos. La edad actual del universo se estima en [Cebú] entre 10 ** 10 y 2 * 10 ** 10 años. La muerte del universo se estima en [Nigel] en 10 ** 11 años y en [Drake] como en 10 ** 12 años para un universo cerrado (la gran crisis) o 10 ** 14 años para un universo abierto (la muerte térmica del universo).
Los programas que cumplen con Y10K PUEDEN optar por limitar el rango de fechas que admiten a aquellos que son consistentes con la vida esperada del universo. Los sistemas que cumplen con Y10K DEBEN aceptar fechas 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 de al menos 10 ** 29 años en el pasado y en el futuro.
Trabajo en embedded y pensé que publicaría nuestra solución aquí. Nuestros sistemas están en 32 bits, y lo que vendemos en este momento tiene una garantía de 30 años, lo que significa que se encontrarán con el error del año 2038. La actualización en el futuro no fue una solución.
Para solucionar esto, establecemos la fecha del kernel 28 años antes que la fecha actual. No es una compensación aleatoria, 28 años es, excatly, el tiempo que tomará para que los días de la semana vuelvan a coincidir. Por ejemplo, estoy escribiendo esto el jueves y la próxima vez el 7 de marzo será un jueves en 28 años.
Además, todas las aplicaciones que interactúan con las fechas en nuestros sistemas tomarán la fecha (time_t) del sistema para convertirla a un time64_t personalizado y aplicar la compensación de 28 años a la fecha correcta.
Creamos una biblioteca personalizada para manejar esto. El código que estamos utilizando se basa en esto: https://github.com/android/platform_bionic
Por lo tanto, con esta solución puede comprarse 28 años extra fácilmente.
Visual Studio pasó a una representación de 64 bit de time_t en Visual Studio 2005 (mientras que todavía deja _time32_t para 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 lo indica sysrqb, el problema será resuelto por su compilador.