¿Por qué el 1 de enero de 1970?

Bell Labs lo eligió como una fecha reciente y redonda cuando se lanzó Unix v1 en 1971. Versiones prototipo anteriores usaban 1971-01-01 con ticks de 1/60 de segundo; el desbordamiento de un contador de 32 bits habría ocurrido en unos 2,3 años, por lo que el equipo cambió a segundos enteros y retrocedió la época al 1970-01-01 UTC. Fue práctico, no teológico.

¿Los segundos intercalares se cuentan en el tiempo Unix?

No. POSIX define un timestamp Unix como el número de segundos desde la época asumiendo exactamente 86.400 segundos por día, todos los días. UTC real ha insertado ocasionalmente un segundo intercalar (el más reciente fue el 30 de junio de 2017). La mayoría de los sistemas lo manejan congelando el contador un segundo o “diluyendo” el segundo intercalar a lo largo de un intervalo más largo (el enfoque de Google). El resultado: el mismo timestamp Unix puede corresponder a dos instantes reales distintos durante un segundo intercalar positivo.

¿Qué se rompe exactamente en 2038?

El 19 de enero de 2038 a las 03:14:07 UTC, un contador de segundos desde la época de 32 bits con signo se desbordará a un número negativo que representa el 13 de diciembre de 1901. Cualquier sistema de 32 bits, dispositivo embebido, formato de archivo o columna de base de datos que use un int32 con signo para el tiempo fallará. Linux de 64 bits migró hace años; la exposición restante está en sistemas embebidos, formatos de archivo heredados (timestamps de inodos ext2/3, timestamps DOS de ZIP) y columnas SQL declaradas explícitamente como INT.

¿Debo almacenar timestamps como enteros o como cadenas ISO 8601?

Enteros si vas a hacer aritmética y el tamaño de almacenamiento importa. Cadenas ISO 8601 si los humanos leerán los datos o necesitas preservar la zona horaria original. Muchos sistemas almacenan ambos: epoch en ms UTC para ordenar y aritmética, más la cadena ISO original con zona horaria para auditoría. No almacenes números de época en hora local; en el momento en que un servidor cambie de zona horaria, los datos estarán silenciosamente corruptos.

¿Cuál es la diferencia entre segundos, milisegundos, microsegundos y nanosegundos?

Pura escala. Date.now() de JavaScript está en milisegundos desde la época. Las llamadas al sistema Unix como clock_gettime(CLOCK_REALTIME) típicamente devuelven nanosegundos. Los tipos TIMESTAMP de bases de datos varían según el proveedor: Postgres usa microsegundos, MySQL DATETIME(6) usa microsegundos, SQL Server usa ticks de 100 ns. Siempre documenta la unidad en el límite de la API.

¿Es un timestamp Unix consciente de la zona horaria?

Sí y no. El timestamp en sí es un conteo absoluto de segundos desde un instante UTC fijo, por lo que es inequívoco. Pero no lleva zona horaria de visualización: convertirlo de vuelta a una fecha de calendario requiere elegir una zona horaria. Un timestamp de 1700000000 es el mismo momento físico en todas partes, pero se muestra como 14 de noviembre en Tokio y 13 de noviembre en Los Ángeles.

Guide

Unix Timestamps Explicados: Época, Precisión y el Problema del Año 2038

El formato de tiempo más común del mundo es un truco de 56 años con una mecha de 12 años.

By Buğra SözeriPublished May 31, 2026

Un timestamp Unix es un único entero que fija un momento en el tiempo. Es el formato de tiempo más utilizado en informática: cada base de datos, línea de log, JWT y cookie HTTP en última instancia se apoya en él. También está lleno de trampas que no se anuncian hasta que tus datos ya están mal.

Qué es, con precisión

Un timestamp Unix es el número de segundos (o milisegundos, microsegundos, nanosegundos, elige una unidad) transcurridos desde 1970-01-01T00:00:00 UTC, comúnmente llamado “la época Unix”. Hoy ese número está en los 1,7 mil millones para segundos o 1,7 billones para milisegundos.

Puedes convertir un timestamp a y desde una fecha de calendario con nuestro conversor de timestamps: pega cualquier entero y ve la fecha UTC, tu fecha local y el tiempo relativo.

¿Por qué 1970?

La elección no es profunda. Bell Labs lanzó Unix v1 en 1971 y necesitaba una fecha reciente arbitraria para el contador de tiempo. Un prototipo anterior contaba ticks de 1/60 de segundo desde 1971-01-01, pero el contador de 32 bits se habría desbordado en poco menos de 2,5 años. El equipo cambió a segundos enteros y retrocedió la época al 1970-01-01 para que las fechas anteriores pudieran representarse como números negativos. Se quedó porque cada sistema posterior lo adoptó.

Precisión: segundos, ms, μs, ns

Las distintas capas de la arquitectura usan unidades diferentes:

Segundos — Unix clásico time(), reclamaciones JWT iat/exp, cabeceras HTTP Date, la mayoría de exportaciones de hojas de cálculo.
Milisegundos — JavaScript Date.now(), Java System.currentTimeMillis(), timestamps de registros Kafka, MongoDB ObjectId (los primeros 4 bytes son segundos-desde-época, empaquetados junto con otros campos en BSON).
Microsegundos — Postgres TIMESTAMP, MySQL DATETIME(6), bibliotecas de trazado (Jaeger, OpenTelemetry).
Nanosegundos — Linux clock_gettime(CLOCK_REALTIME), Go time.Now().UnixNano(), etcd, exportadores recientes de OpenTelemetry.

En un límite de API, nunca asumas. 1700000000 es noviembre de 2023 si se lee como segundos, enero de 1970 más 20 días si se lee como milisegundos. Una heurística rápida: si el entero tiene aproximadamente 10 dígitos, son segundos; 13, milisegundos; 16, microsegundos; 19, nanosegundos. Nuestra herramienta de timestamps detecta los cuatro automáticamente.

Segundos intercalares: la mentira en el fondo

POSIX define un timestamp Unix como “segundos desde la época” asumiendo explícitamente que cada día tiene 86.400 segundos. UTC real no lo hace. Desde 1972, se han insertado 27 segundos intercalares positivos para mantener UTC alineado con la rotación de la Tierra. El más reciente fue el 30 de junio de 2017.

El comportamiento estricto de POSIX es congelar el reloj durante un segundo intercalar: el timestamp 1483228827se sirve dos veces seguidas. Esto rompe la monotonía y hace fallar todo lo que asume que los timestamps son únicos. La alternativa de Google, el “smearing de segundos intercalares”, distribuye el segundo extra a lo largo de una ventana de 24 horas para que ningún segundo individual se repita; AWS, Meta y Microsoft hacen lo mismo. Dos servidores que usan esquemas diferentes pueden discrepar hasta medio segundo alrededor de un evento intercalar.

Para el 99% de las aplicaciones esto no importa. Para cualquier cosa que ordene eventos con precisión sub-segundo entre múltiples proveedores, importa absolutamente.

El problema del año 2038

Un entero de 32 bits con signo puede contener valores desde −2.147.483.648 hasta +2.147.483.647. Interpretado como segundos desde 1970-01-01 UTC, el límite superior es 2038-01-19T03:14:07Z. Un segundo después, el contador se desborda al valor más negativo, representando el 13 de diciembre de 1901.

Los sistemas operativos modernos de 64 bits ya usan time_t de 64 bits, que no se desbordará por otros 292 mil millones de años. La exposición que queda:

Dispositivos embebidos — ECUs de automóviles, PLCs industriales, implantes médicos. Muchos todavía usan tiempo de 32 bits y no se actualizan.
Formatos de archivo — timestamps de inodos ext2/ext3, ZIP clásico (formato DOS), atributos extendidos NTFS más antiguos.
Columnas SQL — una columna declarada INTpara “ahorrar espacio” en segundos de época. Audita tus esquemas ahora, no en 2037.
Código C heredado compilado contra una libc antigua en ARM de 32 bits. La migración a time_t de 64 bits es una ruptura ABI y muchos proveedores no la han lanzado.

Para un tratamiento más extenso, consulta nuestra entrada del glosario de Unix timestamp.

Unix time vs ISO 8601

ISO 8601 (y su perfil de Internet, RFC 3339) escribe el tiempo como 2026-05-31T14:30:00Z. Es legible por humanos, consciente de la zona horaria y auto-descriptivo. El tiempo Unix es compacto, ordenable como entero e inequívoco sobre el instante real, pero no dice nada sobre la zona horaria que el escritor pretendía para la visualización.

Usa ISO 8601 en APIs, logs y en cualquier lugar donde un humano leerá el valor. Usa enteros Unix en almacenamiento cuando el espacio y la aritmética importan, o cuando la ordenación debe ser barata. Muchos sistemas llevan ambos: el entero para operaciones, la cadena para rastros de auditoría. Consulta la entrada del glosario ISO 8601 para la gramática completa.

Errores comunes

Análisis sin zona horaria

new Date("2026-05-31") en JavaScript se analiza como medianoche UTC, pero new Date("2026-05-31 14:00") (nota el espacio, no una T) se analiza como hora local en la mayoría de los motores. Los timestamps Unix resultantes difieren según tu desplazamiento. Incluye siempre el designador de zona horaria (Z, +09:00) en las entradas que no controlas completamente.

Mezclar unidades silenciosamente

Un microservicio que emite milisegundos habla con un receptor que espera segundos. El receptor ve timestamps en el año 55000 y los escribe silenciosamente en la base de datos. Siempre valida la magnitud de los timestamps entrantes contra un rango plausible.

Épocas en hora local

Algunos sistemas heredados calculan “segundos desde 1970-01-01 hora local”. Esto no es tiempo Unix y falla en el momento en que un servidor se mueve o el horario de verano cambia. Si heredas uno de estos, registra el desplazamiento junto al entero y convierte a época UTC verdadera en el límite.

Prueba el conversor

Pega cualquier entero en nuestro conversor de timestamps para ver las interpretaciones UTC y local una al lado de la otra, con detección automática de segundos/ms/μs/ns. Para conversión en lote o controles de precisión adicionales, la herramienta de timestamps maneja ambas direcciones.

Conclusión

El tiempo Unix es un gran valor predeterminado porque es compacto, ordenable e inequívoco sobre el instante. Es un pésimo valor predeterminado en el momento en que olvidas en qué unidad estás, qué zona horaria pretendes mostrar o si tu almacenamiento es de 32 bits. La época fue una elección pragmática en 1970; el precipicio del año 2038 es la factura que llega. Audita tus columnas de enteros, documenta tus unidades y no almacenes épocas en hora local.

Frequently asked questions

¿Por qué el 1 de enero de 1970?: Bell Labs lo eligió como una fecha reciente y redonda cuando se lanzó Unix v1 en 1971. Versiones prototipo anteriores usaban 1971-01-01 con ticks de 1/60 de segundo; el desbordamiento de un contador de 32 bits habría ocurrido en unos 2,3 años, por lo que el equipo cambió a segundos enteros y retrocedió la época al 1970-01-01 UTC. Fue práctico, no teológico.
¿Los segundos intercalares se cuentan en el tiempo Unix?: No. POSIX define un timestamp Unix como el número de segundos desde la época asumiendo exactamente 86.400 segundos por día, todos los días. UTC real ha insertado ocasionalmente un segundo intercalar (el más reciente fue el 30 de junio de 2017). La mayoría de los sistemas lo manejan congelando el contador un segundo o “diluyendo” el segundo intercalar a lo largo de un intervalo más largo (el enfoque de Google). El resultado: el mismo timestamp Unix puede corresponder a dos instantes reales distintos durante un segundo intercalar positivo.
¿Qué se rompe exactamente en 2038?: El 19 de enero de 2038 a las 03:14:07 UTC, un contador de segundos desde la época de 32 bits con signo se desbordará a un número negativo que representa el 13 de diciembre de 1901. Cualquier sistema de 32 bits, dispositivo embebido, formato de archivo o columna de base de datos que use un int32 con signo para el tiempo fallará. Linux de 64 bits migró hace años; la exposición restante está en sistemas embebidos, formatos de archivo heredados (timestamps de inodos ext2/3, timestamps DOS de ZIP) y columnas SQL declaradas explícitamente como INT.
¿Debo almacenar timestamps como enteros o como cadenas ISO 8601?: Enteros si vas a hacer aritmética y el tamaño de almacenamiento importa. Cadenas ISO 8601 si los humanos leerán los datos o necesitas preservar la zona horaria original. Muchos sistemas almacenan ambos: epoch en ms UTC para ordenar y aritmética, más la cadena ISO original con zona horaria para auditoría. No almacenes números de época en hora local; en el momento en que un servidor cambie de zona horaria, los datos estarán silenciosamente corruptos.
¿Cuál es la diferencia entre segundos, milisegundos, microsegundos y nanosegundos?: Pura escala. Date.now() de JavaScript está en milisegundos desde la época. Las llamadas al sistema Unix como clock_gettime(CLOCK_REALTIME) típicamente devuelven nanosegundos. Los tipos TIMESTAMP de bases de datos varían según el proveedor: Postgres usa microsegundos, MySQL DATETIME(6) usa microsegundos, SQL Server usa ticks de 100 ns. Siempre documenta la unidad en el límite de la API.
¿Es un timestamp Unix consciente de la zona horaria?: Sí y no. El timestamp en sí es un conteo absoluto de segundos desde un instante UTC fijo, por lo que es inequívoco. Pero no lleva zona horaria de visualización: convertirlo de vuelta a una fecha de calendario requiere elegir una zona horaria. Un timestamp de 1700000000 es el mismo momento físico en todas partes, pero se muestra como 14 de noviembre en Tokio y 13 de noviembre en Los Ángeles.

Published May 31, 2026