Segundos vs milisegundos
1777118400
1777118400000
Ambos valores representan el mismo instante si el primero se interpreta como segundos y el segundo como milisegundos. Confundirlos es el bug más típico al trabajar con timestamps.
Convierte entre marcas Unix, ISO 8601, UTC y hora local.
Última actualización
177723989317772398930002026-04-26T21:44:53.000Z2026-04-26 21:44:53Sun, 26 Apr 2026 21:44:53 GMTUn conversor de Unix timestamp transforma el *epoch time* — un único número que representa un instante concreto — en fechas legibles, y vuelve a convertir esas fechas en timestamps. Como desarrollador los ves en todas partes: columnas de bases de datos, líneas de log, respuestas de APIs, eventos de analítica, el claim exp de un JWT, disparadores de tareas programadas o cabeceras de expiración de caché.
La idea es sencilla: los ordenadores guardan el tiempo como un número (segundos o milisegundos desde 1970-01-01 00:00:00 UTC), pero las personas necesitamos calendarios, zonas horarias y formatos legibles. Convertir entre ambos mundos es una de las tareas de depuración más habituales en cualquier app web o móvil.
La parte más confusa son las *unidades*. POSIX y la mayoría de lenguajes de backend usan segundos. JavaScript, Java y muchos brokers de mensajería usan milisegundos. Algunos sistemas de métricas usan microsegundos o nanosegundos. Un número de 10 dígitos casi siempre son segundos; uno de 13 dígitos casi siempre son milisegundos.
1970-01-01 00:00:00 UTC).2026-04-25T12:00:00Z) es un formato de texto portable. La Z final (o +00:00) significa UTC; un offset como +02:00 indica una hora local que va 2 horas por delante de UTC.Pega un número (segundos o milisegundos) o una cadena de fecha. El conversor detecta el formato automáticamente según su longitud y forma.
Cambia entre segundos y milisegundos si la detección automática se equivoca: 10 dígitos son segundos, 13 dígitos son milisegundos.
La salida muestra ISO 8601 en UTC, tu hora local y una expresión relativa legible (hace 3 horas, dentro de 2 días).
Copia el timestamp, la cadena ISO o la hora local directamente. Útil para rellenar el exp de un JWT, una fila de la base de datos o una consulta a logs.
Los formatos que más vas a ver al trabajar con fechas y horas en código. ISO 8601 también está descrito por la IETF como RFC 3339 para su uso en protocolos.
| Formato | Ejemplo | Dónde aparece |
|---|---|---|
| Unix en segundos | 1777118400 | Logs de backend, exp de JWT, time() de POSIX, Redis |
| Unix en milisegundos | 1777118400000 | Date.now() de JavaScript, System.currentTimeMillis() de Java |
| ISO 8601 en UTC | 2026-04-25T12:00:00Z | APIs REST, JSON, GraphQL, ficheros de log |
| ISO 8601 con offset | 2026-04-25T14:00:00+02:00 | Programación visible para el usuario, invitaciones de calendario |
| RFC 2822 | Sat, 25 Apr 2026 12:00:00 GMT | Cabeceras de correo, Date y Last-Modified en HTTP |
| Solo fecha | 2026-04-25 | Cumpleaños, festivos: sin información de zona horaria |
1777118400
1777118400000
Ambos valores representan el mismo instante si el primero se interpreta como segundos y el segundo como milisegundos. Confundirlos es el bug más típico al trabajar con timestamps.
{ "id": 42, "createdAt": 1777118400, "expiresAt": 1777204800}Convierte cada valor antes de dar por hecho si está en el pasado o en el futuro. La mayoría de APIs JSON usan Unix en segundos, pero siempre revisa la documentación: los backends muy basados en JavaScript suelen emitir milisegundos.
2026-04-25T12:00:00Z
2026-04-25T14:00:00+02:00
Estas dos cadenas representan el *mismo instante*. Guarda siempre los momentos en UTC y formatea a hora local solo al mostrarlos.
1700000000 leído como segundos es noviembre de 2023, pero leído como milisegundos es enero de 1970.'2026-04-25') en lugar de comparar timestamps. Dos cadenas ISO válidas pueden describir el mismo instante con formatos distintos.1970-01-01 00:00:00 UTC. Es un único número que representa un instante concreto, sin depender de ninguna zona horaria.Date.now() de JavaScript devuelve milisegundos; la mayoría de backends devuelven segundos.Date de JavaScript guarda los timestamps como milisegundos desde el epoch de Unix: ese es el valor que devuelven Date.now() y new Date().getTime(). Ofrece más precisión que los segundos, pero es una fuente habitual de bugs por factor 1000 al integrarse con otros lenguajes.new Date(...) en JavaScript, o usa datetime.fromtimestamp(...) en Python. O pégalo en un conversor de Unix timestamp para obtener el resultado en un clic.2038-01-19: es el famoso problema del año 2038. Los lenguajes y bases de datos modernos guardan los timestamps en enteros de 64 bits, lo que extiende el rango seguro durante cientos de miles de millones de años.