Un reloj que en realidad es un solo número
Casi todos los dispositivos que has tocado hoy se ponen de acuerdo en un número. No en la hora de tu ciudad, ni en tu calendario, ni en tu zona horaria: un único número entero que cuenta los segundos transcurridos desde la medianoche del 1 de enero de 1970 en UTC. Ese número se llama tiempo Unix, y ahora mismo es una cifra de diez dígitos que aumenta en uno cada segundo.
Es una idea elegante. En lugar de almacenar “martes, las 3 de la tarde en Madrid”, con todas sus reglas humanas, una máquina guarda algo como 1771200000. Un instante, un número, sin ambigüedad. Tu servidor en Fráncfort, tu teléfono en Lima y un sensor en una fábrica coinciden en él aunque sus relojes de pared muestren cosas distintas. Puedes ver el número actual y traducirlo a una fecha legible en nuestro conversor de timestamp Unix.
El problema es que un número que solo sube tarde o temprano se queda sin espacio. Y para una forma muy concreta y muy común de almacenar el tiempo Unix, sabemos exactamente cuándo: las 03:14:07 UTC del 19 de enero de 2038.
Por qué 1970
El punto de partida, llamado “época” (epoch), es el 1 de enero de 1970. No tiene nada de cósmico. A principios de los años setenta, los ingenieros que construían Unix en los Laboratorios Bell necesitaban una fecha cero cómoda y reciente, y un comienzo de década redondo servía perfectamente. Los instantes anteriores a 1970 simplemente se representan con números negativos.
Esa decisión modesta se extendió por todo el mundo digital. Hoy el tiempo Unix está dentro de bases de datos, protocolos de red, sistemas de archivos, registros y firmware de aparatos que sus creadores nunca imaginaron. La fecha de origen casi nunca importa. Lo que importa es cuánto espacio reservó el ordenador para guardar el número.
El número que se agota
Durante décadas, la forma habitual de almacenar el tiempo Unix fue un entero de 32 bits con signo. “Con signo” quiere decir que un bit se reserva para distinguir números positivos y negativos, lo que deja un valor máximo de 2.147.483.647. Esa es la cantidad de segundos que ese contador puede alojar.
Suma 2.147.483.647 segundos a la medianoche de 1970 y llegas a las 03:14:07 UTC del martes 19 de enero de 2038. Un segundo más y el contador se desborda. Como el bit de signo cambia, el número no salta a 2.147.483.648: se vuelve negativo y aterriza el 13 de diciembre de 1901. Imagina el cuentakilómetros de un coche viejo que pasa de 999999 a 000000, salvo que aquí el coche aparece de pronto en el siglo anterior.
Hay un detalle que a los aficionados les encanta: la hora límite es 03:14:07, es decir 3, 14, 7, un guiño a los primeros dígitos de pi. El tiempo Unix tiene varios de estos momentos celebrados, y el de 2038 es simplemente el primero que rompe cosas en lugar de adornar una camiseta.
| Valor de tiempo Unix | Momento (UTC) | Por qué se recuerda |
|---|---|---|
| 0 | 1 de enero de 1970, 00:00:00 | La época: el segundo cero del que todo cuelga. |
| 1.000.000.000 | 9 de septiembre de 2001, 01:46:40 | El “Unix billennium”, celebrado por programadores. |
| 1.234.567.890 | 13 de febrero de 2009, 23:31:30 | Una cuenta atrás con dígitos ordenados; hubo fiestas reales. |
| 2.147.483.647 | 19 de enero de 2038, 03:14:07 | El techo de los 32 bits con signo: el problema del año 2038. |
Por qué no es el efecto 2000 con otro disfraz
Es tentador archivar esto junto al efecto 2000 (Y2K) y seguir con la vida. Pero son problemas distintos. El efecto 2000 fue una convención humana: el software guardaba los años con dos cifras, así que “99” pasaba a “00” y el ordenador no sabía si era 1900 o 2000. Era un problema de formato, en gran medida en la capa donde las personas leen y escriben fechas.
El año 2038 es más profundo. No se trata de cómo se muestra una fecha, sino de la unidad fundamental con la que la máquina cuenta el tiempo. No puedes arreglarlo escribiendo años con cuatro cifras en una pantalla; hay que ampliar el propio recipiente que guarda el número.
| Efecto 2000 | Año 2038 | |
|---|---|---|
| Raíz del problema | Años guardados con dos dígitos | Segundos guardados en 32 bits con signo |
| Capa afectada | Formato y presentación | El tipo de dato y el almacenamiento subyacente |
| Solución típica | Usar años de cuatro cifras | Usar enteros de 64 bits para el tiempo |
| Más difícil de cambiar | Lógica de aplicación | Formatos en disco, protocolos y aparatos antiguos |
Lo más curioso: 2038 ya está rompiendo cosas
El error sutil es pensar que se trata de un acantilado lejano. No lo es. Cualquier sistema que calcule fechas hacia el futuro ya cruza la frontera de 2038 hoy mismo. Una hipoteca a treinta años firmada en 2026 calcula vencimientos posteriores a 2038. Un certificado, una garantía, una póliza o una suscripción a largo plazo hacen aritmética que pasa por encima del límite mucho antes de que llegue la fecha.
Por eso ya se han visto fallos aislados: un sistema que intenta representar “dentro de veinte años” en un entero de 32 bits obtiene de pronto una fecha de 1901, un plazo negativo o un error inexplicable. El año 2038 no espera a 2038. Llega antes a cualquier código que mire lo bastante lejos hacia adelante.
Dónde duele de verdad, y dónde no
La buena noticia es que tu portátil y tu teléfono casi con seguridad están a salvo. Los sistemas operativos modernos de 64 bits ya guardan el tiempo Unix en enteros de 64 bits. JavaScript cuenta el tiempo en milisegundos dentro de un número de coma flotante que no tiene problemas hasta dentro de cientos de miles de años. Python usa enteros de precisión ilimitada. Para la mayoría del software actualizado, 2038 es una nota a pie de página.
El peligro vive en otra parte: en aparatos de 32 bits con vidas largas y actualizaciones raras. Routers, controladores industriales, contadores inteligentes, equipos médicos, centralitas de coches y sensores que se instalan y se olvidan durante veinte o treinta años. También en los formatos: campos de fecha fijos de 32 bits dentro de archivos, protocolos de red, sistemas de archivos antiguos y columnas de bases de datos diseñadas hace mucho. La CPU puede estar lista, pero los datos guardados con el formato viejo no se arreglan solos.
El arreglo es aburrido, y eso es bueno
La solución principal es sencilla de describir: guardar el tiempo en un entero de 64 bits con signo en lugar de 32. Eso amplía el alcance del contador hasta unos 292.000 millones de años, mucho más que la edad del universo. No hace falta inventar nada nuevo; basta con dar más espacio al número.
Gran parte de ese trabajo ya está hecho. El núcleo de Linux dedicó años a hacer seguras frente a 2038 incluso a las plataformas de 32 bits, las bibliotecas estándar se actualizaron y los BSD hicieron lo propio. La parte difícil no son los procesadores, sino los datos en reposo: migrar formatos de archivo, protocolos y aparatos antiguos sin romper todo lo que ya depende de ellos. Es trabajo silencioso, poco glamuroso y profundamente útil; exactamente como debe ser una buena ingeniería de infraestructura.
Qué puedes hacer
- Comprueba si tu lenguaje o base de datos guarda el tiempo en 32 o en 64 bits, sobre todo en sistemas antiguos.
- Busca cualquier sitio donde calcules fechas a años o décadas vista; ese código cruza 2038 hoy.
- Revisa los aparatos embebidos y el firmware con vidas largas, donde las actualizaciones son raras.
- Trata las fechas en disco y en los protocolos como contratos: cambiar el tamaño de un campo de tiempo afecta a todo lo que lo lee.
- Prueba el reloj de tu sistema más allá de 2038 en un entorno controlado para ver qué se rompe antes de que importe.
Un número que merece la pena vigilar
El problema del año 2038 es un buen recordatorio de que el tiempo digital es una elección humana, no una ley natural. Decidimos contar segundos, decidimos empezar en 1970 y decidimos cuántos bits dedicarle. Cada una de esas decisiones era razonable cuando se tomó, y cada una deja una huella que perdura décadas.
Mientras tanto, el contador sigue subiendo en silencio, un segundo cada segundo. Si tienes curiosidad por verlo, mira el número actual en nuestro conversor de timestamp Unix, confirma la fecha de hoy o calcula cuánto falta para una fecha futura con la calculadora de plazos. Y si te interesan los errores de tiempo que ya rompen software hoy, nuestra guía sobre los bugs de fecha y hora más comunes continúa la historia.