El Problema del Año 2038 (Y2K38)

¿Qué es el problema del año 2038?

El problema del año 2038 (también conocido como Y2K38 o el error del milenio de Unix) es un problema de desbordamiento de fecha que afecta a los sistemas que almacenan marcas de tiempo Unix como un entero con signo de 32 bits. El valor máximo de un entero con signo de 32 bits es 2.147.483.647, que corresponde a las 03:14:07 UTC del 19 de enero de 2038. Un segundo después, el contador se desborda hasta el valor de 32 bits más negativo, que representa el 13 de diciembre de 1901, causando errores de fecha catastróficos.

¿Por qué ocurre?

Un entero con signo de 32 bits puede almacenar valores desde -2.147.483.648 hasta 2.147.483.647. Cuando se diseñaron las marcas de tiempo Unix a principios de los años 70, el año 2038 parecía imposiblemente lejano. Pero los sistemas embebidos, las bases de datos y el código heredado escritos entonces todavía funcionan hoy.

¿Qué sistemas están en riesgo?

Sistemas embebidos: controladores industriales, routers y dispositivos IoT que usan time_t de C de 32 bits
Bases de datos heredadas: columnas TIMESTAMP de MySQL (rango: 1970-2038)
Kernels de Linux antiguos: sistemas Linux de 32 bits que usan time_t como entero con signo de 32 bits
Sistemas de archivos: algunos formatos de archivo almacenan las fechas de modificación en campos de 32 bits
Software financiero: cualquier sistema que programe eventos posteriores al 19 de enero de 2038

La solución: usar marcas de tiempo de 64 bits

Un entero con signo de 64 bits puede representar marcas de tiempo hasta el año 292.277.026.596, muy por encima de cualquier preocupación práctica. La mayoría de los sistemas modernos ya usan tiempo de 64 bits:

# Python — uses 64-bit internally, safe
import time
print(time.time())  # works past 2038

# C — use int64_t or time64_t instead of time_t on 32-bit systems
#include <stdint.h>
int64_t ts = (int64_t)time(NULL);

# MySQL — use DATETIME (range: 1000–9999) instead of TIMESTAMP
ALTER TABLE events MODIFY created_at DATETIME NOT NULL;

Estado actual

Los sistemas Linux de 64 bits (la gran mayoría hoy en día) están a salvo: time_t tiene 64 bits en plataformas de 64 bits.
MySQL 8.0.28+ extendió TIMESTAMP para admitir fechas posteriores a 2038 en algunas configuraciones.
El kernel de Linux corrigió el time_t de 32 bits para plataformas de 32 bits en el kernel 5.6 (2020).
Miles de millones de dispositivos embebidos de 32 bits siguen siendo vulnerables y puede que nunca se actualicen.

Qué deberías hacer hoy

Audita cualquier sistema que programe o almacene fechas posteriores a enero de 2038. Migra las columnas de base de datos TIMESTAMP a DATETIME o BIGINT. Asegúrate de que cualquier código embebido de 32 bits use bibliotecas de tiempo de 64 bits. El problema tiene solución completa, pero solo si actúas antes de la fecha límite.