Qué es el timestamp Unix y por qué existe el problema de 2038

Un timestamp Unix es el número de segundos que han pasado desde el 1 de enero de 1970 a las 00:00 UTC, ese instante de referencia que se conoce como epoch. Es una sola cifra —sin formato, sin zona horaria, sin ambigüedad— que representa un momento exacto en el tiempo. Puedes convertir un timestamp Unix a fecha legible, o al revés, con la herramienta de Docuboxer, que trabaja en local y admite tanto hora local como UTC.

Por qué el tiempo se cuenta desde 1970

No hay una razón matemática ni astronómica detrás del 1 de enero de 1970: fue una decisión práctica de los ingenieros que diseñaban Unix a principios de esa década. Necesitaban un punto de partida reciente y redondo para no gastar memoria representando fechas remotas que el sistema nunca iba a usar. Se quedó fijo por la misma razón que se quedan fijas casi todas las convenciones técnicas: una vez que miles de programas empezaron a asumir ese punto cero, cambiarlo habría roto la compatibilidad de todo lo construido encima. Hoy el epoch Unix es el estándar de facto para representar tiempo en bases de datos, APIs, logs y protocolos de red.

Segundos o milisegundos: el detalle que más rompe cosas

Este es, en la práctica, el error más frecuente al trabajar con timestamps. Unix define el epoch en segundos, pero muchos lenguajes y APIs —empezando por Date.now() de JavaScript— devuelven milisegundos. La forma rápida de distinguirlos es contar dígitos: un timestamp de 10 dígitos son segundos (algo como 1755561600), uno de 13 dígitos son milisegundos (1755561600000).

Confundir uno con otro produce resultados absurdos pero silenciosos: si tratas 13 dígitos como si fueran segundos, la fecha resultante cae alrededor del año 55000; si tratas 10 dígitos como milisegundos, aterrizas en enero de 1970. Ninguno de los dos errores lanza una excepción —el cálculo es válido, solo que la fecha no tiene sentido— por lo que suele pasar desapercibido hasta que alguien nota un dato con fecha "1970-01-20" en producción. Antes de convertir cualquier timestamp, cuenta los dígitos.

El epoch siempre es UTC — la zona horaria es solo presentación

Un timestamp Unix no lleva zona horaria incorporada: es siempre el número de segundos desde el epoch en UTC, sin excepción. Cuando una interfaz te muestra "15 de agosto de 2026, 14:00" a partir de un timestamp, esa hora local es una capa de presentación calculada en el momento de mostrarla —aplicando el desfase de tu zona horaria—, no algo almacenado en el dato. El mismo timestamp produce horas distintas para alguien en Madrid, en Ciudad de México o en Tokio, pero representa exactamente el mismo instante en el tiempo. Es una distinción útil al depurar: si dos sistemas "no coinciden en la hora", casi siempre es un problema de presentación (a qué zona horaria se está convirtiendo), no del dato subyacente.

El problema del año 2038

Muchos sistemas antiguos almacenan el timestamp Unix como un entero de 32 bits con signo. Ese tipo de dato solo puede representar valores hasta 2.147.483.647 — y ese número de segundos desde el epoch se alcanza el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el contador desborda: en aritmética con signo, el siguiente valor se interpreta como negativo, y la fecha calculada salta hacia atrás hasta el 13 de diciembre de 1901. Es el mismo tipo de fallo, en espíritu, que el problema del año 2000 con las fechas de dos dígitos, pero con una causa distinta: no es un atajo de formato, es un límite físico del tipo de dato.

Dónde sigue siendo un riesgo real hoy: sistemas embebidos y firmware que rara vez reciben actualizaciones (controladores industriales, electrónica de vehículos, dispositivos IoT con años de vida útil por delante), formatos de archivo definidos hace décadas con campos de fecha de 32 bits, y columnas de bases de datos creadas como INT en sistemas que llevan mucho tiempo en producción y nadie ha revisado. Dónde ya está resuelto: cualquier sistema moderno de 64 bits —la inmensa mayoría del software de servidor y de escritorio actual— usa un entero de 64 bits para el tiempo, cuyo rango llega hasta el año 292.000 millones. Para esos sistemas, 2038 no es un problema.

Un matiz honesto: los segundos intercalares

El epoch Unix ignora los segundos intercalares (leap seconds), esos ajustes ocasionales que se añaden al reloj oficial para compensar que la rotación de la Tierra no es perfectamente constante. Esto hace que restar dos timestamps Unix sea sencillo y predecible —siempre representa el mismo número de segundos de reloj—, pero significa que el epoch Unix no es una escala de tiempo físicamente perfecta: en teoría, dos timestamps separados por exactamente 86.400 pueden no corresponder a exactamente un día solar. En la práctica, para el 99% de los usos —ordenar eventos, calcular expiraciones, medir duraciones— esta diferencia es irrelevante.

Timestamps en JWT: también en segundos

Si trabajas con autenticación, es habitual encontrarte timestamps Unix dentro de un JWT: los campos exp (fecha de expiración) e iat (emitido en) siguen el estándar de segundos desde el epoch, igual que el resto del ecosistema Unix — no milisegundos, aunque tu código JavaScript trabaje internamente con milisegundos. Es una fuente habitual de bugs al validar tokens a mano: si comparas un exp en segundos contra un Date.now() en milisegundos sin convertir, el token parece expirado mil veces antes de tiempo, o nunca expira.

Pruébalo con un timestamp real

Abre el conversor de timestamp Unix y pega 1755561600: verás la fecha correspondiente tanto en tu hora local como en UTC, y podrás hacer la conversión inversa desde cualquier fecha legible. Si necesitas revisar el valor crudo en otras bases —por ejemplo para depurar cómo se almacena internamente— el conversor de bases numéricas convierte ese mismo entero a hexadecimal o binario. Y si el timestamp aparece dentro de un payload, el formateador de JSON ayuda a localizarlo y verificar sus dígitos de un vistazo.

Preguntas frecuentes

Herramientas relacionadas

• Convertir timestamp Unix — Epoch a fecha legible, local o UTC.
• Calculadora de fechas — Suma, resta y diferencias entre fechas.
• Conversor de bases numéricas — Decimal, hexadecimal, binario y octal.
• Decodificar JWT — Inspecciona los timestamps exp e iat de un token.

También te puede interesar: qué es Base64 y para qué sirve, la codificación que usan los propios JWT por dentro.