En el año 2000, el efecto 2000 llegó y pasó sin muchos problemas. A pesar de las predicciones de un fallo generalizado, se evitó la crisis gracias a la planificación e intervención a largo plazo y de última hora, y no falló ningún sistema crítico. En los años posteriores, los pocos sistemas operativos y aplicaciones que se vieron afectados han sido, en la mayoría de los casos, actualizados, sustituidos o retirados.
Si utiliza un sistema basado en Unix o Linux, hay otro fallo relacionado con la fecha del que tendrá que preocuparse: en el año 2038.
Todos los sistemas de 32 bits basados en Unix/Linux almacenan internamente la hora del reloj del sistema como el número de segundos desde el Epoch, o 00:00:00 del 1 de enero de 1970. Este tipo de datos interno, time_t, es en la mayoría de los casos un entero con signo de 32 bits (4 bytes). Si el sistema en cuestión sigue el estándar POSIX (como lo hacen la mayoría de los sistemas Unix y Linux), la última hora y fecha que pueden representarse como segundos desde la Época en ese entero con signo de 32 bits es 3:14:07 UTC del martes 19 de enero de 2038.
Después de esta hora y fecha, la representación interna de la hora del sistema llegará a 2147483647, el número más alto almacenable en un entero con signo de 32 bits. Un segundo después, llegará a un número negativo, -2147483648. Las aplicaciones actuales interpretarán este número negativo como un año más antiguo (1901) o congelarán el reloj del sistema a las 03:14:07 del 19/1/2038. Esto posiblemente hará que las aplicaciones y los sistemas operativos fallen, ya que no están diseñados para trabajar con un reloj de sistema colgado o que muestre el año como 1901.
No hay soluciones viables (que no rompan las aplicaciones existentes) para los sistemas que utilizan procesadores de 32 bits, o sistemas operativos y aplicaciones que se ejecutan en modo de 32 bits en procesadores de 64 bits. Muchos sistemas operativos actuales de Unix/Linux ya se ejecutan en modo de 64 bits (con un time_t «largo» correspondiente cuando se trata de un procesador de 64 bits; en la mayoría de los casos esto resuelve el problema.
Los sistemas operativos que admiten un time_t largo de 64 bits probablemente no se vean afectados por el fallo del Año 2038 en lo que respecta al reloj interno del sistema. Sin embargo, las aplicaciones que utilizan un time_t de 32 bits pueden seguir fallando, incluso si el sistema que ejecuta la aplicación admite el funcionamiento completo de 64 bits.
Aquí hay un resumen rápido del estado actual del soporte de Unix 2038 en las principales versiones de Unix/Linux:
- Solaris 7 o superior en procesadores UltraSPARC y SPARC64 de 64 bits, así como Solaris 10 en plataformas x86-64, tiene un time_t de 64 bits.
- La versión 4.3.3 de AIX en procesadores PowerPC y Power de 64 bits tiene un time_t de 64 bits.
- El kernel de Linux que se ejecuta en modo de 64 bits en procesadores IA64 o x86-64 tiene un time_t de 64 bits.
- Mac OS X versión 10.4 y posteriores tienen un kernel de 32 bits, pero las aplicaciones pueden utilizar un time_t de 64 bits cuando se ejecutan en CPUs PowerPC G5 o x86-64.
- FreeBSD 6.0 y posteriores tienen un time_t de 64 bits cuando se ejecutan en una plataforma de 64 bits.
- OpenBSD 4.1 y posteriores soportan un time_t de 64 bits.
- NetBSD aún no tiene un time_t de 64 bits, pero se está intentando solucionar el problema para una próxima versión.
Incluso si su sistema operativo actual aún no es seguro para Unix 2038, ¡no se preocupe! La gente ha sido consciente del problema desde hace muchos años, y están trabajando activamente en las soluciones. En la mayoría de los casos, el problema se resolverá haciendo que el sistema operativo y las aplicaciones se ejecuten finalmente en modo de 64 bits.
Espero que todos los principales sistemas operativos de escritorio sean completamente de 64 bits en los próximos cinco a diez años. Además, un efecto de goteo ayudará a sustituir los sistemas actuales por configuraciones de 64 bits cuando sea aplicable y rentable.
Acerca del autor: Bill Bradford es el creador y mantenedor de SunHELP y vive en Houston, Texas, con su esposa Amy.