Conversor de Marca de Tiempo Unix
Conversor de marca de tiempo Unix — pega cualquier epoch (segundos o milisegundos, detectados automáticamente) y obtén una fecha legible en UTC y en tu zona horaria local. Funciona en el navegador, sin subir nada.
Sobre el conversor de marca de tiempo Unix
Una marca de tiempo Unix (también llamada epoch time o POSIX time) es el número de segundos transcurridos desde el 1970-01-01 00:00:00 UTC, sin contar los segundos intercalares. Es la lengua franca del cómputo del tiempo informático — cada equipo Linux, carga útil de API REST, token JWT, fila de base de datos y línea de registro almacena el tiempo así, porque un solo entero con signo es portable, comparable y libre de zona horaria. Los desarrolladores y SRE se topan con marcas de tiempo constantemente: siguiendo una traza de pila, reproduciendo un webhook, alineando dos eventos entre servidores en regiones distintas, o demostrando que una fila se escribió antes de un despliegue. Este conversor gestiona todas las variantes habituales en un solo campo de entrada. Detecta automáticamente la unidad según el número de dígitos — 10 dígitos son segundos, 13 son milisegundos (JavaScript Date.now()), 16 son microsegundos (Python time.time_ns()/1000), 19 son nanosegundos (Go time.Now().UnixNano()). También mantiene tus datos en tu máquina: las marcas de tiempo de los registros pueden filtrar sin querer ids de petición, ids de cliente e instantes de incidentes, así que nunca subimos lo que pegas — los cálculos se hacen en tu navegador. Para el trabajo práctico, cubre las situaciones que realmente te encuentras a las 2 de la madrugada. Pegar un número de la respuesta de una API JSON, un ObjectId de MongoDB, un extract(epoch from now()) de Postgres, un registro de Cloudflare o una cabecera de registro de Kafka te dice al instante a qué momento apunta, en UTC y en tu zona horaria local. Ir en el otro sentido — de fecha a marca de tiempo — es igual de rápido: elige una fecha, copia el valor en segundos para date +%s, MySQL UNIX_TIMESTAMP() o iat/exp de JWT. La confusión entre segundos y milisegundos es el error más frecuente aquí, así que el número de dígitos se muestra junto a la entrada, y los valores de ida y vuelta para ambas unidades aparecen en la salida para que puedas buscar en tu código y elegir la correcta. No hay registro, ni seguimiento publicitario ni límite de peticiones.
Por qué usar este conversor de marca de tiempo Unix
Segundos y milisegundos, detección automática
Pega cualquier número y el conversor detecta la unidad por su longitud: 10 dígitos son segundos, 13 son milisegundos (Java / JavaScript Date.now()), 16 son microsegundos, 19 son nanosegundos. Nunca tendrás que recordar dividir entre 1000.
Salida con zona horaria
Cada resultado se muestra en UTC, en la zona horaria local de tu navegador, en ISO 8601, en RFC 1123 y en forma relativa legible por humanos («hace 3 horas»). Copia el que necesite tu informe de error, ticket de JIRA o commit de git.
Funciona localmente, nada se sube
Las marcas de tiempo de los registros pueden ser sensibles — delimitan ids de petición, ids de usuario y ventanas de incidentes. Toda la conversión ocurre en tu navegador; no se envía nada a un servidor. Seguro para pegar marcas de tiempo de producción.
Ida y vuelta lista para cualquier stack
El mismo valor se muestra como segundos Unix, milisegundos Unix, ISO 8601 y Excel/FILETIME/Ticks de .NET. Úsalo directamente en date +%s, iat de JWT, FROM_UNIXTIME de MySQL o DateTimeOffset.FromUnixTimeSeconds de .NET.
Preguntas frecuentes
¿Cómo convierto una marca de tiempo Unix a una fecha?
Pega la marca de tiempo en el campo de arriba. El conversor detecta si son segundos o milisegundos contando los dígitos (10 = segundos, 13 = milisegundos) y muestra el momento en UTC, en la zona horaria local de tu navegador y en ISO 8601. Por ejemplo, 1700000000 es 2023-11-14T22:13:20 UTC. Si prefieres hacerlo con código: JavaScript new Date(1700000000 * 1000).toISOString(), Python datetime.utcfromtimestamp(1700000000), o Linux date -u -d @1700000000.
¿Cuál es la diferencia entre segundos y milisegundos en una marca de tiempo?
Ambos cuentan desde el mismo epoch (1970-01-01 00:00:00 UTC), pero en unidades distintas. Los segundos Unix — usados por date +%s de Linux, UNIX_TIMESTAMP() de MySQL, time.time() de Python (como entero), extract(epoch from now()) de PostgreSQL, iat/exp de JWT — tienen hoy unos 10 dígitos (por ejemplo, 1700000000). Los milisegundos — usados por Date.now() de JavaScript, System.currentTimeMillis() de Java, Date de MongoDB — tienen unos 13 dígitos (por ejemplo, 1700000000000). El conversor detecta la unidad por el número de dígitos, así que no tienes que recordar multiplicar o dividir entre 1000.
¿Cómo obtengo la marca de tiempo Unix actual?
Distintos stacks la exponen de forma diferente. JavaScript: Math.floor(Date.now() / 1000) para segundos, Date.now() para milisegundos. Python: int(time.time()) o time.time_ns() // 1_000_000_000. Bash / Linux: date +%s para segundos, date +%s%3N para milisegundos. Go: time.Now().Unix() o .UnixMilli(). PHP: time(). MySQL: SELECT UNIX_TIMESTAMP(). PostgreSQL: SELECT EXTRACT(epoch FROM now())::bigint. La herramienta de arriba también muestra la marca de tiempo actual en directo, actualizándose cada segundo — cópiala con un clic.
¿Qué es el problema del año 2038 (Y2038)?
Una marca de tiempo Unix con signo de 32 bits puede almacenar valores de hasta 2 147 483 647 — lo que corresponde al 2038-01-19 03:14:07 UTC. Un segundo después se desborda y vuelve a un número negativo, alrededor de diciembre de 1901. El fallo afecta al código C heredado que usa time_t como int32, además de firmware embebido antiguo, inodos ext3 y algunos protocolos (NTPv4 se desborda en 2036). Los sistemas modernos de 64 bits, el Number de JavaScript, el long de Java y los kernels de Linux actuales usan marcas de tiempo de 64 bits, cuyo desbordamiento está a 292 000 millones de años. Si tu stack sigue con hora de 32 bits, arréglalo antes de 2038.
¿Cómo convierto milisegundos a segundos?
Divide entre 1000 y (normalmente) descarta el resto. En JavaScript: Math.floor(Date.now() / 1000). En Python: int(time_ms / 1000) o time_ms // 1000. En SQL: timestamp_ms / 1000. En sentido contrario, multiplica por 1000: secondsTimestamp * 1000. No pierdas precisión sin darte cuenta — si realmente necesitas precisión de subsegundo (eventos financieros, trazas distribuidas, spans de OpenTelemetry), conserva la unidad original y conviértela solo en la capa de presentación.
¿Qué formato usa JavaScript?
Date.now() y (new Date()).getTime() de JavaScript devuelven la hora Unix en milisegundos — un número de 13 dígitos, no segundos. El constructor Date y new Date(ms) también esperan milisegundos. Es el error más común al consumir una API JSON desde un backend en Python o Linux: si pasas un valor de 10 dígitos en segundos a new Date(), obtendrás una fecha de 1970. Multiplica siempre los segundos por 1000 antes de pasarlos a Date, o usa new Date(seconds * 1000).
¿Cómo convierto ISO 8601 a una marca de tiempo Unix?
Usa la pestaña Fecha → marca de tiempo de arriba y la herramienta devolverá tanto segundos como milisegundos, además de un eco en ISO 8601 para que confirmes la interpretación de la zona horaria. En código: JavaScript Math.floor(new Date('2026-06-15T12:00:00Z').getTime() / 1000); Python int(datetime.fromisoformat('2026-06-15T12:00:00+00:00').timestamp()); Bash date -d '2026-06-15T12:00:00Z' +%s. Incluye siempre una zona horaria en la cadena ISO (Z o ±HH:MM) — de lo contrario, el analizador recurre a la zona horaria local de la máquina y obtendrás un número distinto en cada servidor.
¿Por qué las marcas de tiempo Unix suelen expresarse en UTC?
Porque una marca de tiempo Unix no tiene zona horaria — es simplemente un recuento de segundos desde un único instante fijo en UTC. Dos servidores en Nueva York y Tokio que ejecuten time.time() exactamente en el mismo instante producen el mismo número. La zona horaria de visualización es una decisión de presentación que se toma más tarde. Almacenar las marcas de tiempo en UTC (o como enteros Unix sin procesar) y convertirlas a hora local solo en la capa de interfaz es el patrón estándar; almacenar la hora local en una base de datos es lo que provoca errores de horario de verano y filas de hora duplicada en el cambio de hora de otoño.