Convertir timestamp
El conversor de marcas de tiempo Unix convierte un timestamp en todas las representaciones útiles del mismo instante, y también al revés. La unidad se detecta por la magnitud y se indica: el mismo entero es un momento de 1970 o de 2026 según cuente segundos o milisegundos, y un conversor que adivina en silencio produce una fecha que parece plausible y está equivocada por un factor de mil.
Escribe una marca de tiempo o fecha ISO arriba, o pulsa «Ahora, aquí» o «Cargar ejemplo».
¿Cómo funciona Convertir timestamp?
La aritmética es trivial. Averiguar qué representa realmente el número que tienes delante no lo es, y ahí es donde ocurren los errores.
Un timestamp Unix no lleva unidades
1757577600 son segundos desde 1970 y cae el 11 de septiembre de 2025. Leído como milisegundos cae el 21 de enero de 1970. Leído como microsegundos, veintinueve minutos después de la medianoche del 1 de enero de 1970. Nada en el valor dice cuál es, así que la unidad se infiere de la magnitud —diez dígitos o menos son segundos, de once a trece son milisegundos, y así— y la inferencia se muestra junto al resultado en lugar de aplicarse en silencio. Esa distinción importa: una inferencia que puedes ver es un dato que puedes corregir.
El año 2038 no es hipotético
Un time_t de 32 bits con signo se agota a las 03:14:07 UTC del 19 de enero de 2038, cuando desborda y pasa a 1901. Los sistemas operativos modernos pasaron a 64 bits hace años, pero el firmware de los sistemas embebidos, los formatos de archivo antiguos y algunas columnas de bases de datos no, y el código que guarda un timestamp en una columna INT tiene el mismo techo. Aparece en los ejemplos de abajo porque merece la pena probar contra él.
El desfase horario pertenece al instante, no a la zona
Londres está en +00:00 en enero y en +01:00 en julio, así que “Europe/London” no identifica un desfase —identifica un conjunto de reglas para deducirlo a partir de una fecha—. La salida ISO de aquí lee el desfase de tu instante concreto en la base de datos de zonas horarias de la plataforma en lugar de calcularlo, y eso es lo que lo hace correcto al cruzar un cambio de horario de verano. Cualquier cosa que fije el desfase en el código se equivoca dos veces al año.
El tiempo Unix no tiene segundos intercalares
Un timestamp Unix se define como el número de segundos sin intercalares desde la época, lo que significa que no puede representar uno. Cuando se inserta un segundo intercalar, las implementaciones repiten un valor o reparten el segundo extra a lo largo del día. Así, la diferencia entre dos timestamps Unix no es exactamente el tiempo físico transcurrido —se lleva 27 segundos de diferencia desde 1972, algo que no importa para casi nada y que importa muchísimo para las pocas cosas para las que importa.
Los números de semana ISO no son lo que la gente espera
Según ISO 8601 la semana empieza en lunes y la semana 1 es la que contiene el primer jueves, así que el 1 de enero a veces cae en la semana 52 o 53 del año anterior. Por eso un panel puede mostrar una semana 53 que otro muestra como semana 1, y ambos tienen razón bajo reglas distintas.
Entrada
1757577600
Resuelto
unit seconds (10 digits or fewer) ISO 2025-09-11T08:00:00.000Z RFC 2822 Thu, 11 Sep 2025 08:00:00 GMT relative last year
¿Qué opciones y casos límite admite Convertir timestamp?
| Parámetro | Tipo | Valor predeterminado | Comportamiento y casos límite |
|---|---|---|---|
| 10 dígitos o menos | segundos | detectado | La unidad clásica del epoch de Unix, y lo que casi toda API y base de datos entiende por timestamp. |
| 11 a 13 dígitos | milisegundos | detectado | Lo que devuelve Date.now de JavaScript, y lo que emiten la mayoría de las API JSON escritas en JavaScript. |
| 14 a 16 dígitos | microsegundos | detectado | Los timestamps internos de Postgres y time.time_ns de Python dividido entre mil. |
| 17 dígitos o más | nanosegundos | detectado | time.UnixNano de Go y el formato de exposición de Prometheus. |
| ISO 8601 | cadena de fecha | aceptado | 2026-09-11T08:00:00Z y sus variantes. Una cadena ISO sin zona se lee como hora local en la plataforma; es una ambigüedad genuina del formato, no una decisión tomada aquí. |
| Relativo | expresión | aceptado | `3 days ago`, `2 hours`, `now`. Mes y año son aproximaciones, porque ninguno de los dos tiene una duración fija. |
| Zona horaria | nombre IANA | tu zona local | El desfase se lee de la base de datos de la plataforma para ese instante concreto, así que es correcto a ambos lados de un cambio de horario de verano. |
| Semana ISO | 1 a 53 | calculado | Las semanas empiezan en lunes; la semana 1 contiene el primer jueves. Por eso el 1 de enero puede caer en la semana 52 o 53 del año anterior. |
Preguntas frecuentes
¿Por qué mi timestamp se resolvió en 1970?
Casi seguro pegaste segundos donde se esperaban milisegundos, o al revés. Esta herramienta detecta la unidad por la magnitud y te dice cuál eligió, así que revisa primero esa línea. Un número de diez dígitos son segundos; uno de trece dígitos son milisegundos. Multiplicar o dividir entre mil es toda la solución.
Segundos o milisegundos, ¿qué debería usar mi API?
Segundos, salvo que de verdad necesites precisión inferior al segundo, y di cuál usas en tu documentación de todos modos. Segundos es lo que Unix, la mayoría de las bases de datos y la mayoría de los lenguajes entienden por timestamp; milisegundos es lo que entiende JavaScript. Los errores salen de la frontera entre ambos, así que la disciplina útil es nombrar la unidad en el propio campo: created_at_ms en lugar de created_at.
¿Qué pasa de verdad en 2038?
Un time_t de 32 bits con signo desborda a las 03:14:07 UTC del 19 de enero de 2038 y da la vuelta a diciembre de 1901. Los sistemas de 64 bits están bien y llevan años siéndolo; lo que no está bien es el firmware embebido que seguirá ejecutándose, los formatos de archivo con un campo de 32 bits y las columnas de base de datos tipadas como INT en vez de BIGINT. De todo eso, lo último es lo más probable que esté ahora mismo en tu base de código.
¿Por qué mi cadena ISO está desfasada una hora?
Normalmente, por el horario de verano. Un desfase es una propiedad de un instante concreto, no de una zona: Londres está en +00:00 en enero y en +01:00 en julio. Esta herramienta lee el desfase de la base de datos de zonas horarias de la plataforma para tu instante exacto, así que cambia al cruzar el límite —lo cual es correcto, y es la razón por la que un desfase fijado en el código está mal medio año.
¿El tiempo Unix incluye los segundos intercalares?
No, por definición —cuenta segundos sin intercalares, así que no tiene forma de representar uno—. Cuando se inserta un segundo intercalar, los sistemas repiten un valor de timestamp o reparten el segundo extra a lo largo del día. La consecuencia práctica es que restar dos timestamps Unix te da tiempo civil transcurrido, no tiempo físico transcurrido; desde 1972 la diferencia entre ambos es de 27 segundos.
¿Se sube mi timestamp?
No. Cada conversión de aquí es aritmética más la base de datos de zonas horarias Intl del propio navegador, ejecutándose en la pestaña que ya tienes abierta. No hay nada en convertir una fecha que necesite un servidor, y los timestamps que la gente convierte suelen salir de logs de producción.