Marca de tiempo Unix

Una marca de tiempo Unix (o tiempo POSIX, o segundos desde la época) es el número de segundos que han transcurrido desde 1970-01-01 00:00:00 UTC, ignorando los segundos intercalares. A fecha de 2026-05-16, la marca de tiempo Unix es aproximadamente 1.779.000.000.

Por qué este formato domina la informática:

• Es un solo entero. Sin zona horaria, calendario, configuración regional ni ambigüedad de horario de verano.
• La aritmética de tiempo es trivial — reste dos marcas de tiempo para obtener una duración en segundos.
• Ordenable como números. Los índices de bases de datos y las consultas de series temporales no necesitan comparadores sofisticados.
• Compacto en almacenamiento y en la red.

Tres variantes que encontrará:

• Segundos. El original. 1700000000 = 14 nov 2023 22:13:20 UTC.
• Milisegundos. Date.now() de JavaScript devuelve esto. Multiplique el valor en segundos por 1000.
• Microsegundos / nanosegundos. Telemetría de alta resolución, trazas distribuidas. El timestamptz de Postgres almacena microsegundos.

Dos problemas bien conocidos:

• Año 2038 (Y2K38). Un entero con signo de 32 bits de segundos desborda el 2038-01-19 a las 03:14:07 UTC. Los sistemas modernos usan 64 bits (válido durante ~292 mil millones de años); los sistemas embebidos heredados pueden no hacerlo.
• Segundos intercalares. UTC inserta segundos intercalares ocasionales para mantenerse sincronizado con la rotación de la Tierra. El tiempo Unix los ignora — la marca de tiempo en el instante del segundo intercalar es ambigua. La mayoría de los sistemas de producción usan un smear (Google, AWS) que distribuye el segundo intercalar a lo largo de horas.

Convierta marcas de tiempo Unix a fechas legibles (y viceversa) pasándolas a una biblioteca de fechas. La conversión a una hora de reloj de pared siempre requiere una elección de zona horaria — el mismo instante es “3pm en NYC” y “medianoche en Tokio” dependiendo de qué zona se muestre. Vea nuestro conversor de zona horaria.

Cómo los sistemas operativos están migrando del time_t de 32 bits: Linux integró time_t de 64 bits como la ABI estándar del kernel en 2020 (kernel 5.6+) y glibc 2.32 (2020) lo expuso al espacio de usuario. NetBSD hizo el cambio en 2012, OpenBSD en 2014. FreeBSD siguió en 2024. Las superficies rezagadas restantes son sistemas embebidos ejecutando kernels más antiguos fijados, ciertos protocolos en cadena que codificaron marcas de tiempo de 32 bits en su formato de cable (el encabezado de bloque de Bitcoin incluye una marca de tiempo Unix de 32 bits, problemática en ~2106 cuando ocurriría el desbordamiento sin signo), y formatos de archivo heredados (los archivos ZIP usan marcas de tiempo DOS de 32 bits con una época de 1980; tar usa marcas de tiempo Unix de 32 bits). El trabajo duro es encontrar y corregir estos; el lado del kernel está en gran medida hecho. Referencia: POSIX.1-2017 §4.16 — Segundos desde la Época.

Ejemplo práctico

Convertir 1700000000 a una fecha UTC legible por humanos. Dividir y tomar módulo desde segundos: 1.700.000.000 / 86400 = 19.675,93 días desde 1970-01-01. El día 19.675 es 2023-11-14 (aritmética de calendario). La fracción 0,93 de un día × 86.400 = 80.000 segundos = 22:13:20. Entonces 1700000000 = 2023-11-14T22:13:20Z. Verificar en JavaScript: new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z". Para mostrar en Tokio (UTC+9): añadir 9 horas = 2023-11-15T07:13:20+09:00. El mismo instante, diferente reloj de pared. El bug clásico: almacenar new Date().getTime() (milisegundos) en una columna que el resto del código trata como segundos — cada marca de tiempo acaba leyéndose como el año 55.000+ cuando se muestra.

Cuándo y por qué importa

Siempre que dos sistemas intercambian datos de tiempo — frontend a backend, base de datos a pipeline ETL, microservicio a microservicio — las marcas de tiempo Unix son la única representación que no lleva ambigüedad de zona horaria, configuración regional, calendario o horario de verano. Almacene marcas de tiempo como segundos o milisegundos Unix en una columna de 64 bits, formatee a ISO-8601 con zona horaria explícita solo en el borde para visualización humana. El hábito defensivo: en cada nombre de columna o campo de API que lleva tiempo, codifique la unidad (created_at_ms, expires_at_unix_seconds) para que un revisor de código no pueda confundir el orden de magnitud. El riesgo de Y2038 es pequeño para los nuevos sistemas pero real para cualquier marca de tiempo de 32 bits en formatos de cable de protocolo y sensores embebidos — audítelos ahora mientras hay 12 años de margen, no en 2037 cuando los parches sean urgentes. Referencia: RFC 3339 — Fecha y Hora en Internet.