Conversor de Timestamp Unix
Pega un epoch en segundos, milisegundos, microsegundos o nanosegundos y mira la fecha en tu zona horaria, en UTC y en ISO 8601. La unidad se detecta por la cantidad de dígitos. También puedes pegar una fecha para obtener su epoch.
Todavía no hay valor
Pega un timestamp o una fecha en el campo. Todos los formatos aparecen aquí al instante, cada uno con botón de copiar.
Fecha a timestamp
Elige fecha y hora. El epoch se calcula en la zona UTC, la misma seleccionada arriba.
Convertir líneas de log
Pega líneas de log, JSON o CSV. Cada número de 10, 13, 16 o 19 dígitos se convierte en fecha ISO 8601 en la zona UTC. Las líneas se quedan en tu navegador.
¿El timestamp vino del exp, iat o nbf de un JWT? El decodificador muestra el token completo y dice si ya caducó.
¿Solo necesitas una fecha como ISO String o cadena UTC? El conversor de formatos de fecha lo hace en un clic.
Timestamp en código
Cómo obtener el timestamp actual y convertir en los dos sentidos en los lenguajes más comunes.
// Now, in seconds and in milliseconds
Math.floor(Date.now() / 1000); // 1790254800
Date.now(); // 1790254800123
// Epoch to date (Date expects milliseconds)
new Date(1790254800 * 1000).toISOString();
// Date to epoch in seconds
Math.floor(new Date("2026-09-24T10:00:00-03:00").getTime() / 1000);Qué es un Unix timestamp
Un Unix timestamp, o epoch, es la cantidad de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC, sin contar segundos intercalares. El mismo número representa el mismo instante en cualquier parte del mundo, y por eso aparece en columnas de base de datos, logs, colas de mensajes, respuestas de API y en los claims exp, iat y nbf de un JWT. La zona horaria solo importa al mostrar la fecha a una persona.
Segundos, milisegundos, microsegundos o nanosegundos
La unidad no viene escrita en el número. Para fechas entre 2001 y 2286, la cantidad de dígitos lo resuelve: cada unidad más fina suma 3 dígitos. Así detecta la unidad este conversor.
| Dígitos | Unidad | Ejemplo | Dónde suele aparecer |
|---|---|---|---|
| 10 | Segundos | 1790254800 | time() de PHP, int(time.time()) de Python, exp del JWT, EXTRACT(EPOCH) de PostgreSQL, propiedad timestamp de RabbitMQ |
| 13 | Milisegundos | 1790254800000 | Date.now() de JavaScript, System.currentTimeMillis() de Java, timestamp de registro de Kafka, SentTimestamp de SQS |
| 16 | Microsegundos | 1790254800000000 | UNIX_MICROS de BigQuery, time.time_ns() // 1000 de Python, tracing |
| 19 | Nanosegundos | 1790254800000000000 | UnixNano() de Go, time.time_ns() de Python, InfluxDB y métricas |
UTC y hora local
Un timestamp no tiene zona horaria. La aplica quien lo muestra: new Date(ms).toISOString() muestra UTC y toLocaleString() usa la zona del navegador. Por eso dos computadoras en zonas distintas muestran horas distintas para el mismo valor. Cuando una fecha sale corrida un número exacto de horas, casi siempre es UTC leído como hora local, o al revés.
Una fecha en 1970 o miles de años en el futuro
Los dos síntomas vienen del mismo cambio de unidad. Un valor en segundos pasado a new Date() de JavaScript, que espera milisegundos, se convierte en enero de 1970. Un Date.now() guardado en un campo que el backend lee en segundos se convierte en una fecha decenas de miles de años en el futuro. Convertir el número aquí muestra al instante cuál de los dos pasó.
Horario de verano y fechas antiguas
Las reglas de las zonas horarias cambian con el tiempo. Brasil, por ejemplo, tuvo horario de verano hasta febrero de 2019, y en esos períodos São Paulo estaba en UTC−2 y no en UTC−3. Un sistema que convierte fechas antiguas con un offset fijo se equivoca en una hora con todo lo que cayó en verano. La base de zonas horarias IANA, que usan este conversor y los navegadores, guarda las reglas de cada año, y el resultado lleva un aviso cuando la fecha cae en horario de verano.
El problema del año 2038
El mayor entero con signo de 32 bits es 2147483647, que corresponde al 19/01/2038 a las 03:14:07 UTC. Un segundo después, los sistemas que guardan el epoch en 32 bits vuelven a 1901. El tipo TIMESTAMP de MySQL tiene ese límite. Las columnas BIGINT y los lenguajes con enteros de 64 bits no, y este conversor acepta fechas mucho después de 2038.
Timestamp negativo
Los valores negativos son fechas anteriores a 1970: −86400 es el 31/12/1969 en UTC. Fechas de nacimiento y registros históricos pueden generarlos, y algunas bases de datos y bibliotecas antiguas no los aceptan. Conviene incluir uno en los datos de prueba.
Inicio y fin del día en otra zona
El 24 de septiembre en São Paulo empieza a las 03:00 UTC, no a la medianoche UTC. Un filtro BETWEEN armado con el inicio del día en UTC trae registros del día equivocado. La tabla de inicio y fin de este conversor usa la zona elegida, y el fin de un período es el último milisegundo antes del siguiente.
Preguntas frecuentes sobre Unix timestamp
Unidades, zonas horarias y los errores de fecha que más aparecen en logs y APIs.