El problema del año 2038 (Y2K38) explicado
El 19 de enero de 2038 a las 03:14:07 UTC, el timestamp Unix 2.147.483.647 — el valor máximo de un entero con signo de 32 bits — se desbordará. Esto es lo que significa, qué sistemas se ven afectados y por qué la mayoría del código moderno ya está a salvo.
¿Qué es el problema del año 2038?
Los timestamps Unix se almacenan tradicionalmente como un entero con signo de 32 bits que cuenta los segundos desde el 1 de enero de 1970 00:00:00 UTC. El valor máximo de un entero con signo de 32 bits es 2,147,483,647, que corresponde al 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el entero se desborda a -2,147,483,648. Interpretado como timestamp Unix, ese valor negativo corresponde al 13 de diciembre de 1901, enviando a los sistemas afectados casi 137 años al pasado.
Los valores del desbordamiento
- 2^31 − 1 = 2,147,483,647 (máximo entero con signo de 32 bits)
- 2,147,483,647 como fecha = 19 de enero de 2038 03:14:07 UTC
- 2,147,483,647 + 1 se desborda a −2,147,483,648 (el valor de 32 bits más negativo)
- −2,147,483,648 como fecha = 13 de diciembre de 1901 20:45:52 UTC
¿Qué sistemas están en riesgo?
El problema afecta a los sistemas que almacenan timestamps como enteros con signo de 32 bits:
- Sistemas embebidos y microcontroladores con time_t de 32 bits
- Código C y C++ heredado compilado para destinos de 32 bits que usa time_t o int para timestamps
- Kernels de Linux antiguos (anteriores a 5.6) en hardware de 32 bits aún en producción
- Columnas TIMESTAMP de MySQL — limitadas a 2038-01-19; usa DATETIME en su lugar
- Algunos protocolos de red y formatos de archivo que codifican timestamps como valores de 32 bits
- Firmware en sistemas de control industrial y dispositivos IoT con vidas útiles de décadas
¿Qué sistemas son seguros?
La mayoría del código y la infraestructura modernos ya no se ven afectados:
- Cualquier SO de 64 bits — Linux (glibc 2.34+ también corrige el hardware de 32 bits), macOS, Windows
- Python — los timestamps usan floats de 64 bits, seguros mucho más allá del año 292 millones
- JavaScript — Date usa floats IEEE 754 de 64 bits, seguro hasta el año 275,760
- Go y Rust — usan int64 para el tiempo internamente, seguros durante miles de millones de años
- Java — java.time.Instant usa long (64 bits), seguro hasta el año ~292 millones
- PostgreSQL TIMESTAMP — almacena fechas más allá de 2038 correctamente
- MySQL DATETIME — rango 1000-01-01 a 9999-12-31, no afectado
Preguntas frecuentes sobre el año 2038
- ¿Qué es el problema del año 2038?
- El problema del año 2038 (Y2K38) es un fallo por el cual los sistemas que usan enteros con signo de 32 bits para almacenar timestamps Unix se desbordarán el 19 de enero de 2038 a las 03:14:07 UTC. El valor máximo de un entero con signo de 32 bits es 2,147,483,647. Un segundo después, el entero salta a -2,147,483,648, que corresponde al 13 de diciembre de 1901.
- ¿Cuál es el timestamp Unix del 19 de enero de 2038?
- El timestamp Unix del 19 de enero de 2038 a las 03:14:07 UTC es 2,147,483,647, el valor máximo de un entero con signo de 32 bits (2^31 - 1). Es el momento exacto en que ocurre el desbordamiento del año 2038 en sistemas de 32 bits.
- ¿Es Y2K38 lo mismo que el Y2K?
- No. El Y2K (problema del año 2000) se debía a programas que almacenaban los años con 2 dígitos. El Y2K38 se debe a almacenar timestamps Unix como enteros con signo de 32 bits que se desbordan en 2038. Causas distintas, sistemas afectados distintos.
- ¿Se romperá internet en 2038?
- Probablemente no de forma significativa. La mayor parte de la infraestructura de internet ya migró a sistemas de 64 bits. El riesgo se concentra en sistemas embebidos, dispositivos IoT heredados y software que lleva décadas sin actualizarse. Los sistemas operativos, lenguajes y bases de datos modernos ya son seguros.