¿Cómo funcionan los relojes internos de los PC’s?

La gran mayoría de sistemas informáticos tienen implementado un reloj interno cuyo funcionamiento es el siguiente: tomando una fecha base (se cogió 1970 para la mayoría de sistemas), cuenta los segundos que han pasado desde entonces y los almacena en una variable. Para conocer la fecha, se transforman los segundos almacenados por esa variable en la fecha completa (hora-minuto-segundo; día-mes-año). Esto se consigue a través de un algoritmo muy sencillo (más abajo os dejo algunos códigos), y funciona “perfectamente”.

¿Cual es el problema del año 2038?

Hasta ahora la arquitectura más usada es la que se basa en 32-bits. En la mayoría de sistemas de 32-bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero (nombre que designa un tipo de variable en programación comprendida entre unos valores máximos y mínimos) de 32-bits con signo, es decir, que puede representar un rango de números entre -2.147.483.648 y 2.147.483.647 (-2³¹ y 2³¹-1; 1 bit para el signo, y 31 para el valor absoluto), por lo que el último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038, cuando el contador llegue a 2147483647. Un segundo después, el contador se desbordará, y saltará al valor -2.147.483.648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 ó 1970 (dependiendo de la implementación), en vez de 2038. A su vez, esto causaría cálculo y procesamiento incorrecto.

Código simple escrito en C para ver un ejemplo de que pasaría

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main (int argc, char **argv)
{
time_t t;
t = (time_t) 1000000000;
printf (”%d, %s”, (int) t, asctime (gmtime (&t)));
t = (time_t) (0×7FFFFFFF);
printf (”%d, %s”, (int) t, asctime (gmtime (&t)));
t++;
printf (”%d, %s”, (int) t, asctime (gmtime (&t)));
return 0;
}

El resultado sería algo parecido a lo que muestra este gif:

¿Soluciones?

No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición de time_t para usar un tipo de 64-bits rompería la compatibilidad binaria para el software, almacenamiento de datos, y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32-bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo.

La mayoría de sistemas operativos para arquitecturas de 64-bits utilizan enteros de 64-bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete antes del 2038.

Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años, quizás mucho tiempo después de que el sol se haya extinguido.

Enlace | 2038bug
Enlace | Explicación en la wikipedia

Curiosidad

Como una mera nota curiosa, el problema es tan grave, que si por ejemplo buscamos 2038 en Google, éste nos devuelve ni más ni menos que 40.600.000 resultados… unos pocos, ¿no?