Conversor de timestamp
Convierte una marca de tiempo Unix en una fecha legible y viceversa. Obtienes segundos, milisegundos, ISO 8601, UTC, hora local, día de la semana, RFC 2822 y
Convierte entre marcas de tiempo Unix y fechas legibles, en ambos sentidos y tanto en segundos como en milisegundos. Pega 1735689600 o 2026-01-01T00:00:00Z y verás el equivalente en UTC, en tu zona horaria local y en formatos habituales como ISO 8601 y RFC 2822.
Esto aparece constantemente al leer registros de log, al depurar una API que devuelve segundos epoch o al comprobar que la caducidad de un token es la que crees. La conversión es exacta y se ejecuta localmente, y te avisa cuando un valor parece estar en milisegundos en lugar de segundos.
Cómo convertir una marca de tiempo Unix
Pega una marca de tiempo o una fecha
Lee los valores convertidos en UTC y en hora local
Copia el formato que necesites
Preguntas frecuentes
¿Segundos o milisegundos?
Diez dígitos suelen ser segundos y trece suelen ser milisegundos. La herramienta detecta la unidad más probable y te deja cambiarla si el resultado parece incorrecto.
¿Qué es la época Unix?
El recuento de segundos desde el 1 de enero de 1970 00:00:00 UTC, sin contar los segundos intercalares. Es la forma estándar de almacenar un instante.
¿Qué zona horaria se usa?
Se muestran las dos: UTC y la zona horaria local de tu navegador, para que puedas comparar lo que registra el servidor con lo que ves en el reloj.
¿Admite fechas anteriores a 1970?
Sí, los valores negativos representan fechas anteriores a la época, y las fechas muy lejanas en el futuro funcionan hasta los límites del rango de fechas de JavaScript.
¿Puede generar la marca de tiempo de una fecha?
Sí, la conversión funciona en ambos sentidos: introduce una fecha y obtendrás el valor epoch.
¿Se sube algo?
No, la conversión es aritmética local.
De un vistazo
| Entrada | texto |
|---|---|
| Varios archivos | No |
| Dónde se ejecuta | En tu navegador: los archivos no se suben nunca |
| Funciona sin conexión | Sí — una vez cargada la página |
| Precio | Gratis, sin registro y sin marca de agua |
Dónde se rompen las conversiones sin hacer ruido
La mayoría de los errores de conversión no tienen que ver con la sintaxis, sino con el significado. Una columna CSV de códigos postales pierde sus ceros iniciales en el momento en que una hoja de cálculo supone que es un número; un ID largo supera la precisión de coma flotante; las fechas cambian de significado según si van con el día primero o el mes primero. Las claves de JSON no tienen orden, pero los arrays no, y una herramienta que ordena claves no cambia nada, mientras que una que ordena arrays cambia los datos. Unicode es otra trampa: el texto puede llegar como UTF-8, como UTF-16 o con BOM, y un decodificador que adivina mal convierte los caracteres acentuados en «Mojibake». Antes de fiarte de cualquier conversión, revisa la primera y la última fila, cualquier campo con ceros iniciales y cualquier campo que contenga comillas, comas o saltos de línea.
Elegir un formato de datos
JSON es lo predeterminado para todo lo que devuelve una API o lee un programa: maneja estructuras anidadas, números, booleanos y null de forma natural, y todos los lenguajes lo analizan. CSV es más pequeño y se abre directamente en una hoja de cálculo, pero no tiene forma de expresar anidamiento ni un estándar compartido para el delimitador, las comillas o el juego de caracteres, que es justo donde fallan las conversiones. XML es verboso, pero admite atributos, contenido mixto y esquemas, así que sigue dominando los formatos de documento y las integraciones heredadas. YAML es el más legible para configuración, pero es sensible a los espacios y tiene conversiones de tipo sorprendentes («no» se convierte en false, una versión como 1.10 se convierte en 1.1). Elige el formato que prefiera la herramienta que lo va a consumir, no el que se vea más bonito.