Conversor de marcas de tiempo Unix Epoch gratuito

Qué es realmente el tiempo Unix epoch

El tiempo Unix epoch (también llamado tiempo POSIX, tiempo Unix, o simplemente «epoch») es un sistema para representar instantes en el tiempo como un único entero: el número de segundos (o milisegundos, en JavaScript y muchos sistemas modernos) transcurridos desde el epoch Unix a las 00:00:00 UTC del 1 de enero de 1970. Los números negativos representan instantes anteriores al epoch; los positivos, posteriores. La representación por un único entero tiene propiedades atractivas: es independiente de la zona horaria (el número es el mismo en cualquier punto de la Tierra en el mismo instante), es fácil de comparar (los instantes posteriores son números mayores) y el cálculo de duraciones es trivial (resta). El tiempo Unix es la representación subyacente del tiempo en prácticamente todo sistema operativo, todo motor de base de datos, todo protocolo de API y toda biblioteca estándar de lenguaje de programación, incluso los sistemas cuyas interfaces de usuario muestran fechas calendarias almacenan los valores subyacentes como enteros epoch.

La elección del 1 de enero de 1970, y otros epochs

El epoch 1970-01-01 se remonta a los primeros días de Unix en Bell Labs. El tipo time_t de Unix era originalmente un entero con signo de 32 bits que contaba segundos desde una referencia elegida; el equipo escogió el Año Nuevo más reciente antes del inicio del desarrollo, es decir el 1 de enero de 1970. La decisión fue práctica, no filosófica, Unix se desarrolló en 1969-1971, y un epoch reciente maximizaba el rango utilizable de timestamps dentro del rango con signo de 32 bits. Otros sistemas eligieron otros epochs adecuados a sus casos de uso. NTP (Network Time Protocol, RFC 5905) usa el 1 de enero de 1900, importante porque NTP necesitaba abarcar rangos históricos más largos. Windows FILETIME usa el 1 de enero de 1601 como epoch en ticks de 100 nanosegundos (el inicio del ciclo gregoriano de 400 años que incluyó 1601). VAX/VMS usó el 17 de noviembre de 1858 (el epoch del día juliano modificado, popular en astronomía). Mac classic usó el 1 de enero de 1904. JavaScript Date usa el epoch Unix pero cuenta milisegundos en vez de segundos (un flotante de 64 bits, dando ±100 millones de años de rango utilizable). La conclusión: el epoch Unix domina en 2026, pero el registro histórico contiene muchas otras elecciones, cada una con su propia carga de retrocompatibilidad.

El problema Y2K38, el tiempo Unix se va a agotar (más o menos)

Si time_t es un entero con signo de 32 bits (el diseño original de Unix), el timestamp máximo representable es 2 147 483 647, que corresponde al martes 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el valor desborda en negativo y se enrolla hacia el 13 de diciembre de 1901. Este es el problema Y2K38 (también llamado Epochalypse). En los sistemas modernos de 64 bits, time_t es un entero con signo de 64 bits y la fecha de desbordamiento es el 4 de diciembre de 292 277 026 596, cómodamente más allá de la muerte del Sol. Pero los sistemas embebidos de 32 bits siguen en despliegue activo en controladores industriales, satélites de larga misión, back-ends bancarios, redes SCADA del sector petrolero y gasístico, infotainment automotriz y sensores IoT con vidas útiles de varias décadas. La mitigación está en marcha desde principios de los 2000, todo sistema operativo, base de datos y lenguaje grande usa ahora por defecto tiempo de 64 bits sobre hardware de 64 bits (Linux completó la transición en el kernel 5.6, marzo de 2020; Windows siempre usó 64 bits; macOS Catalina abandonó el soporte de 32 bits en 2019). Los sistemas embebidos son la cola larga. El problema Y2K38 no será una crisis de un solo día como lo fue Y2K; será una serie de pequeños fallos en sistemas de cola larga a lo largo de los años que se acerquen a 2038, exactamente como Y2K se manifestó sobre todo en sistemas oscuros que nadie había parcheado.

ISO 8601, el otro formato estándar de tiempo

Donde el tiempo Unix es el formato de transporte, ISO 8601 es el formato legible. Publicado originalmente como ISO 8601:1988, revisado en 2000, 2004 y más recientemente en ISO 8601-1:2019 y ISO 8601-2:2019, el estándar define representaciones como 2026-05-03T14:30:00Z (donde la Z significa UTC) o 2026-05-03T14:30:00+01:00 (con el desplazamiento explícito). La «T» separa la fecha de la hora; el desplazamiento final desambigua la zona horaria. Para los protocolos de internet, RFC 3339 (Klyne y Newman, 2002) define un subconjunto estricto de ISO 8601 más fácil de parsear, es el formato que verás en respuestas JSON de API, timestamps de logs, campos exp/iat de JWT y flujos OAuth. La relación con el tiempo Unix: ISO 8601 es la forma legible de un instante; el tiempo Unix es la forma entera del mismo instante. Un convertidor como este pasa de uno al otro en cualquier dirección. La forma hora local (2026-05-03T14:30:00 sin desplazamiento) es ambigua y debería evitarse en cualquier sistema que cruce zonas horarias, es frecuentemente la fuente de bugs sutiles en los que una API JSON afirma devolver timestamps pero no dice en qué zona están.

Segundos vs milisegundos, la confusión más común

En el nivel del sistema operativo, el tiempo Unix cuenta segundos: un entero de 10 dígitos para cualquier instante entre aproximadamente 2001 y 2286 (los timestamps anteriores a 2001 tenían 9 dígitos o menos). El Date.now() de JavaScript, el System.currentTimeMillis() de la JVM, el DateTimeOffset.ToUnixTimeMilliseconds() de .NET y la mayoría de las API web cuentan en milisegundos: un entero de 13 dígitos para el mismo rango. Las dos formas difieren exactamente en un factor de 1000, y el bug más común relacionado con timestamps en cualquier código que hable con varios sistemas consiste en alimentar un valor en milisegundos a una función que espera segundos (dando una fecha 1000× más lejos en el futuro de lo previsto) o viceversa (dando una fecha a una fracción de segundo después del epoch). Este convertidor detecta automáticamente según la cantidad de dígitos: 10 dígitos o menos = segundos, 13 o más = milisegundos. Para valores intermedios (11–12 dígitos, ambiguos), el convertidor prefiere la interpretación que produzca una fecha sensata. Los microsegundos (16 dígitos, usados por algunos sistemas de alta precisión y muchos tipos TIMESTAMP de bases de datos) y los nanosegundos (19 dígitos, usados por Linux clock_gettime, Go time.UnixNano(), herramientas de observabilidad modernas como OpenTelemetry) también aparecen pero son menos frecuentes en datos cara al usuario.

Dónde realmente necesitas esta conversión

• Lectura de respuestas de API. Un endpoint REST devuelve "created_at": 1714665600: ¿qué fecha es? Pega, lee «2 de mayo de 2024 16:00:00 UTC», sigue con la sesión de depuración. Stripe, GitHub, AWS y la mayoría de las API empresariales usan enteros de tiempo Unix para los campos de fecha precisamente para evitar la ambigüedad de zona horaria.
• Decodificación de timestamps de logs. Los logs de servidor a menudo registran las horas como enteros Unix por compacidad y velocidad de parseo. Leer «1714665600.234 ERROR connection refused» exige convertir el número inicial a una hora calendaria para correlacionar con otros eventos.
• Depuración de JWT. Los claims exp (expiración) e iat (emisión) en JSON Web Tokens son enteros de tiempo Unix según la RFC 7519. Para comprobar si un token ha expirado o ver cuándo se emitió, pega el valor aquí.
• Cálculo de diferencia temporal. Resta dos timestamps Unix para obtener la duración entre ellos en segundos (o milisegundos). Sin matemática de zonas horarias, sin ajuste de DST, sin casos límite de aritmética calendaria.
• Consultas de base de datos con columnas epoch. Muchas bases de datos antiguas almacenan timestamps como enteros Unix. Consultar «todos los eventos entre X e Y» exige convertir las fechas límite legibles en enteros Unix para la cláusula WHERE.
• Planificación y tareas cron. Los sistemas que planifican trabajos por hora absoluta (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) suelen querer objetivos en tiempo Unix en su configuración. Convierte la hora objetivo legible a epoch.
• Decodificación de timestamps «interesantes». Valores epoch famosos: 0 = 1 de enero de 1970 00:00:00 UTC (el propio epoch); 1234567890 = 13 de febrero de 2009 23:31:30 UTC (brevemente celebrado como el momento «Unix billion»); 1500000000 = 14 de julio de 2017 02:40:00 UTC; 2000000000 = 18 de mayo de 2033 03:33:20 UTC; 2147483647 = 19 de enero de 2038 03:14:07 UTC (el punto de desbordamiento Y2K38).

Una nota sobre los segundos intercalares y el tiempo «real»

Una complicación sutil: el tiempo Unix tal y como lo define POSIX no incluye los segundos intercalares. El tiempo universal coordinado (UTC) añade ocasionalmente un segundo intercalar para mantener el tiempo civil alineado con la rotación real de la Tierra, se han añadido 27 segundos intercalares desde que el sistema arrancó en 1972. El tiempo Unix finge que esos segundos intercalares no han ocurrido: cuando se inserta un segundo intercalar al final de un día, el reloj o bien repite el último segundo (comportamiento tradicional de Linux) o lo desparrama sobre un periodo más largo (el enfoque «leap smear» de Google, adoptado por AWS y muchos CDN). Para la mayoría del uso de aplicación, esto no importa, la precisión sub-segundo rara vez es significativa a nivel de aplicación. Para trabajo científico de alta precisión, timestamps de sistemas de trading financiero o timestamps con valor probatorio judicial, el comportamiento ante segundos intercalares es una fuente conocida de casos límite. El IERS (International Earth Rotation and Reference Systems Service) anuncia los segundos intercalares con seis meses de antelación; el más reciente se insertó al final del 31 de diciembre de 2016, y la comunidad internacional ha estado considerando retirar por completo los segundos intercalares (la resolución para hacerlo antes de 2035 fue adoptada en la Conferencia General de Pesas y Medidas de 2022).

Privacidad: conversión solo en el navegador

Los timestamps que pegas no suelen ser sensibles en sí mismos (un entero Unix sólo revela un instante en el tiempo), pero el contexto, una línea de log que contiene un identificador real de usuario junto al timestamp, un JWT con claims sobre un usuario real, una respuesta de API con IDs internos de entidades, frecuentemente lo es. Este convertidor se ejecuta enteramente en tu navegador a través de la API Date integrada de JavaScript. Sin subida, sin registro, verifícalo en la pestaña Red de las DevTools mientras escribes un timestamp (no se dispara ninguna petición), o pon la página sin conexión (modo avión) tras cargarla. La pantalla «now» en actualización continua usa tu reloj local, no una fuente de tiempo de red.

Preguntas frecuentes

¿Qué es un timestamp Unix?

Un timestamp Unix (también llamado tiempo Epoch o tiempo POSIX) es el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, siguiendo la abstracción POSIX de Unix (que no cuenta los segundos intercalares) en lugar de los segundos reales transcurridos del reloj atómico. Muchos sistemas modernos usan milisegundos en lugar de segundos para precisión sub-segundo (Date.now() de JavaScript, System.currentTimeMillis() de Java, DateTimeOffset.ToUnixTimeMilliseconds() de .NET). El tiempo Unix es la representación temporal estándar en prácticamente todo sistema operativo, base de datos y API web.

¿Qué diferencia hay entre segundos y milisegundos?

Un factor de 1000. Los timestamps Unix con precisión de segundos en 2026 tienen 10 dígitos (p. ej., 1714665600); con precisión de milisegundos tienen 13 dígitos (p. ej., 1714665600234). Este convertidor detecta automáticamente según la cantidad de dígitos. El bug más común en código que mezcla las dos formas consiste en alimentar milisegundos a una función que espera segundos (dando una fecha 1000× más lejos en el futuro de lo previsto) o viceversa.

¿Por qué mi hora convertida está desplazada varias horas?

El tiempo Unix es independiente de la zona horaria, pero la forma legible depende de en qué zona lo muestres. El convertidor muestra tres formatos simultáneamente: Hora local (la zona de tu navegador), UTC (Greenwich) e ISO 8601 (con desplazamiento explícito). Si el resultado no coincide con lo que esperabas, comprueba la zona, tu valor «esperado» probablemente estaba en una zona distinta a la del formato que leíste.

¿Qué es el problema Y2K38?

Si el tiempo Unix se almacena en un entero con signo de 32 bits (el diseño original de Unix), desborda el 19 de enero de 2038 a las 03:14:07 UTC. Los sistemas modernos de 64 bits no se ven afectados, la fecha de desbordamiento se desplaza a aproximadamente el año 292 mil millones. El riesgo Y2K38 se concentra en sistemas embebidos de 32 bits aún en despliegue (controladores industriales, satélites, infotainment automotriz, back-ends bancarios, sensores IoT con vidas útiles de varias décadas). A diferencia de Y2K, el problema Y2K38 no será una crisis de un solo día sino una serie de pequeños fallos en sistemas de cola larga a lo largo de los años que se acercan a 2038.

¿Funciona sin conexión?

Sí, una vez cargada la página, toda la conversión se ejecuta en tu navegador a través de la API Date integrada de JavaScript. Sin llamadas de red durante el uso. El botón «Now» usa el reloj local de tu dispositivo; el timestamp en actualización continua de la parte superior se actualiza desde el reloj del sistema sin contactar con ningún servidor de tiempo.

Herramientas relacionadas