Problema del año 2038: qué ocurre con los timestamps Unix de 32 bits

Respuesta breve

El problema del año 2038 afecta a sistemas que almacenan los segundos desde el Unix epoch en un entero con signo de 32 bits. Su máximo es 2147483647, que corresponde a 2038-01-19 03:14:07 UTC. Un segundo después ya no cabe en esa representación, aunque Unix time y los sistemas con rangos mayores continúan.

El límite exacto

Un entero con signo de 32 bits reserva un bit para el signo y dispone de 31 bits para el valor positivo:

máximo = 2³¹ - 1 = 2147483647 segundos

La conversión conocida es:

2147483647 → 2038-01-19T03:14:07Z
2147483648 → 2038-01-19T03:14:08Z

El segundo valor es un timestamp válido como número, pero no cabe en un entero con signo de 32 bits. Puedes comprobar ambas fechas con el conversor de timestamp Unix seleccionando segundos y UTC.

Qué significa «desbordar»

El resultado depende del lenguaje, almacenamiento y operación. Un sistema que hace aritmética con envoltura podría reinterpretar el bit más alto y producir un valor negativo. Otro puede lanzar un error, rechazar la fecha o saturar el campo. No hay una única fecha incorrecta garantizada para todos los programas.

El fallo no está en la definición del instante, sino en el tipo usado para guardarlo o transportarlo. Cambiar la visualización no amplía ese tipo.

Qué sistemas debes revisar

• Bases de datos con columnas enteras de 32 bits para segundos Unix.
• Formatos binarios y protocolos que fijan un campo firmado de cuatro bytes.
• Firmware, dispositivos antiguos y sistemas embebidos con ABI heredada.
• Código que convierte un timestamp mayor a un tipo estrecho antes de validarlo.
• Cálculos de caducidad, certificados o calendarios que ya proyectan fechas más allá de 2038.

Un equipo puede usar un sistema operativo moderno y conservar el problema en un archivo, una base de datos o una dependencia que mantenga el formato viejo.

Segundos, milisegundos y JavaScript

Multiplicar por mil no soluciona el problema si el destino sigue siendo un entero de 32 bits: el límite se alcanza mucho antes. JavaScript Date trabaja con un valor numérico de milisegundos y tiene un rango distinto; que una fecha funcione en el navegador no demuestra que quepa en el sistema receptor.

Conserva la unidad junto al dato y prueba los límites del contrato, no solo los de la interfaz utilizada para convertirlo.

Cómo probar una integración

Incluye al menos estos casos:

1. 0, para verificar el epoch.
2. 2147483647, último segundo del rango firmado de 32 bits.
3. 2147483648, primer valor fuera de ese rango.
4. Una fecha operativa posterior, como 2040.
5. Un valor negativo si el producto admite fechas anteriores a 1970.

Comprueba el valor almacenado, la respuesta de la API y la fecha UTC recuperada. Una prueba que solo valida que la petición no falla puede ocultar una fecha truncada.

Mitigación

Utiliza una representación con rango suficiente de extremo a extremo y migra los datos antes de depender de fechas posteriores. Documenta la unidad, la signatura y el ancho; valida antes de convertir; y revisa todas las fronteras donde el valor cambia de tipo.

La justificación de POSIX sobre segundos desde el epoch documenta el desbordamiento en 2038 de implementaciones con time_t firmado de 32 bits. El riesgo es concreto para esa representación, no una caducidad universal de los timestamps Unix.