Explicación de la marca de tiempo de Unix: segundos, milisegundos, zonas horarias y 2038

Abre casi cualquier archivo de registro, tabla de base de datos o respuesta de API y encontrarás números como 1760000000. Esa es una marca de tiempo de Unix: el número de segundos transcurridos desde 00:00:00 UTC el 1 de enero de 1970, conocido como la época de Unix. Es la forma más común en que los ordenadores representan un momento en el tiempo, y su comprensión evita toda una clase de errores que involucran zonas horarias, verano y análisis de fechas.

¿Por qué contar segundos desde 1970?

Los primeros desarrolladores de Unix necesitaban una representación simple y compacta del tiempo. Contar segundos desde una fecha fija reciente encajaba en un solo número entero, era fácil de comparar y restar, y evitaba la complejidad de los calendarios. La fecha 1 de enero de 1970 era simplemente un punto de partida redondo conveniente cuando Unix estaba siendo construido.

Las ventajas siguen vigentes hoy:

• ** Independiente de la zona horaria.** Una marca de tiempo identifica un instante, no una lectura del reloj de pared. El mismo evento tiene la misma marca horaria en Tokio, Berlín y São Paulo.
• Aritmética fácil. La diferencia entre dos marcas de tiempo es una duración en segundos. Añadiendo 86.400 movimientos hacia adelante en un día.
• ** Compacto y sortable.** Un entero toma 8 bytes y se ordena cronológicamente.
• No hay confusión entre 03/04 que significa 4 de marzo o 3 de abril.

Segundos frente a milisegundos

El error más frecuente con la marca de tiempo es mezclar unidades:

• Las herramientas Unix, la mayoría de las bases de datos, JWT y muchas API utilizan ** segundos **: 10 dígitos hoy, como 1760000000.
• Date.now() de JavaScript, System.currentTimeMillis() de Java y muchos sistemas analíticos utilizan milisegundos: 13 dígitos, como 1760000000000.
• Algunos sistemas utilizan microsegundos (16 dígitos) o nanosegundos (19 dígitos).

Interpretando los milisegundos como segundos se obtiene una fecha de decenas de miles de años en el futuro; el inverso nos lleva a enero de 1970. Si alguna vez ves "1970-01-21" en una interfaz de usuario, alguien pasó segundos donde se esperaban milisegundos. Un convertidor de marca de tiempo detecta la unidad por longitud, que es una verificación rápida de la cordura.

Conversión de las marcas de tiempo en idiomas comunes

• JavaScript *

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

Python

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

Siempre pase tz= en Python; sin él, fromtimestamp devuelve una hora local ingenua que es fácil de malinterpretar.

**SQL (PostgreSQL) **

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

¡Vamos ahora!

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

• ¿Qué quieres decir?

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

Zonas horarias: almacenar UTC, mostrar local

Una marca de tiempo no tiene zona horaria; es un instante absoluto. Se presentan problemas al convertir a y desde fechas legibles por el hombre:

• ** Parsear una fecha sin una zona.** new Date("2026-03-29 02:30") se interpreta en la zona horaria local de cualquier máquina que ejecute el código. En un servidor en UTC y una computadora portátil en Berlín, produce diferentes marcas de tiempo.
• Las diferencias y superposiciones del horario de verano. En las zonas con horario de verano, algunas horas locales no existen (los relojes saltan hacia adelante) y otras ocurren dos veces (los relojes retroceden). Una marca de tiempo no tiene tal ambigüedad.
• ** Almacenando horarios locales.** Si almacena "2026-11-01 01:30" sin una zona, nunca puede estar seguro de qué momento fue.

La regla general: almacenar y transmitir marcas de tiempo o cadenas ISO 8601 con un desplazamiento explícito (2026-10-11T09:30:00Z o +02:00). Convertir a la zona local del usuario sólo cuando se muestra. Almacene el nombre de la zona horaria IANA del usuario (como Europe/Berlin) por separado si necesita programar cosas en su hora local.

ISO 8601 frente a las marcas de tiempo de Unix

Las cadenas ISO 8601 como 2026-10-11T09:30:00Z son legibles para el ser humano y también son inequívocas cuando incluyen Z o un desplazamiento. Muchas APIs las prefieren por legibilidad. Las marcas de tiempo de Unix son más pequeñas y más rápidas de comparar. Ambos están bien; lo importante es la consistencia y siempre incluye información de zona.

segundos bisiestos

La rotación de la Tierra es ligeramente irregular, por lo que el UTC oficial ocasionalmente inserta un segundo bisiesto. El tiempo de Unix los ignora: cada día es exactamente 86.400 segundos, y durante un segundo bisiesto la marca de tiempo se repite o se borra. Para casi todas las aplicaciones, esto es invisible. Si trabaja en un tiempo de alta precisión, use el tiempo TAI o GPS en su lugar. Los organismos internacionales de cronometraje han decidido eliminar gradualmente los segundos bisiestos para 2035, lo que hará que esto sea aún menos preocupante.

El problema del año 2038

Muchos sistemas más antiguos almacenan el tiempo Unix como un entero de 32 bits firmado, cuyo valor máximo es 2.147.483.647. Eso corresponde a las 03:14:07 UTC del 19 de enero de 2038. Un segundo más tarde, el valor se desborda a −2.147.483.648, lo que representa el 13 de diciembre de 1901.

Los sistemas operativos modernos de 64 bits, los lenguajes y las bases de datos utilizan marcas de tiempo de 64 bits, que no se desbordarán durante unos 292 mil millones de años. Los riesgos persisten en:

• Dispositivos integrados y controladores industriales con una larga vida útil.
• Formatos de archivo y protocolos de red con campos de tiempo de 32 bits.
• Columnas de base de datos declaradas como INT de 32 bits que contienen segundos de época. El tipo TIMESTAMP de MySQL tiene un límite de 2038; DATETIME o BIGINT no.

Audite los datos de larga duración ahora, especialmente cualquier cosa que almacene fechas futuras como la expiración de certificados o contratos de 20 años.

Tiempo negativo

Las fechas anteriores a 1970 tienen marcas de tiempo negativas. -86400 es el 31 de diciembre de 1969. La mayoría de los lenguajes modernos los manejan correctamente, pero algunas API y hojas de cálculo más antiguas no, así que prueba las fechas históricas explícitamente.

Lista de verificación de depuración práctica

1. Cuenta los dígitos: 10 para segundos, 13 para milisegundos.
2. Convierte primero a UTC, luego a la hora local, para separar los errores de unidad de los errores de zona.
3. Compruebe si una cadena de fechas incluye Z o un desplazamiento antes de analizarlo.
4. Compare los relojes del servidor y del cliente si los tokens o firmas fallan con errores "expirados" o "todavía no válidos" vea cómo funciona JWT para saber por qué exp y nbf son segundos Unix.
5. Al programar trabajos recurrentes, recuerde que cron se ejecuta en la zona del servidor; estos ejemplos de cron cubren los detalles.

Resumen

Una marca de tiempo Unix es el número de segundos desde 1970-01-01 UTC. Es simple, independiente de las zonas horarias y fácil de calcular. La mayoría de los errores provienen de mezclar segundos y milisegundos, analizar fechas sin zonas, o almacenar horas locales. Almacene UTC, convierta en los bordes, use enteros de 64 bits, y rara vez tendrá que pensar en el tiempo de nuevo.