Convertidor de timestamp
Convierte entre timestamps Unix (segundos/milisegundos) e ISO 8601 / JST / UTC. Útil para analizar logs, depurar APIs y verificar fechas en migraciones de datos.
| Unix (seg) | |
|---|---|
| Unix (ms) | |
| ISO 8601 (UTC) | |
| ISO 8601 (JST) | |
| JST (Hora de Japón) | |
| UTC | |
| RFC 2822 | |
| Día (JST) | |
| Tiempo relativo |
Copiado
📖 Dónde se suele tropezar
Convierte entre marcas de tiempo Unix (segundos o milisegundos) e ISO 8601, JST y UTC. Si un número son segundos o milisegundos se deduce de su longitud: 13 dígitos o más se tratan como milisegundos, 10 como segundos. Es una regla empírica que casi siempre acierta en la práctica, no una especificación. Una marca de tiempo no lleva dentro ni la unidad ni la zona horaria, así que lo único que zanja la duda es la documentación de lo que generó el valor.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| El resultado cae en 1970 o dentro de cincuenta mil años | Es el síntoma clásico de confundir segundos con milisegundos. Lee un valor en milisegundos como si fueran segundos y acabas hacia el año 55000; lee segundos como milisegundos y caes cerca del 20 de enero de 1970. La causa es que los lenguajes no coinciden en la unidad por defecto: Date.now() en JavaScript y System.currentTimeMillis() en Java son milisegundos, mientras que time() en PHP, time.time() en Python y date +%s en el intérprete de comandos son segundos. Salta en cada frontera donde un JSON pasa de un lenguaje a otro. |
Contar dígitos es la prueba más rápida. Desde el 9 de septiembre de 2001, los segundos tienen 10 dígitos y los milisegundos 13, ambos hasta 2286, así que distinguir esos dos casos basta por ahora. En el diseño, meter la unidad en el nombre del campo es lo que menos accidentes provoca: llámalo expires_at_ms en vez de expires_at y quien lo consuma no podrá interpretarlo mal. Mejor todavía, pasa una cadena ISO 8601 si puedes: una persona la lee, así que este tipo de error se detiene en la revisión de código. |
| La misma cadena de fecha da horas distintas según el entorno | Una cadena sin zona horaria la interpreta cada implementación a su manera. En JavaScript, 2024-01-01 (sólo fecha) se lee como UTC mientras que 2024-01-01T00:00:00 (con hora) se lee como local: un carácter de diferencia, nueve horas de desfase. Y una forma separada por espacio como 2024-01-01 09:00:00 queda fuera tanto de ISO 8601 como de ECMAScript, así que cada navegador se inventa su respuesta. Con un servidor en UTC y un portátil en JST, esto aflora como código que funciona en local y se va nueve horas en producción. |
Nunca escribas una cadena sin zona horaria. Añade siempre Z o +09:00: 2024-01-01T00:00:00Z nombra exactamente un instante en cualquier implementación. La regla de operación es guardar en UTC y convertir a local sólo para mostrar. La misma trampa existe en los tipos de columna: los valores TIMESTAMP de MySQL se convierten con la zona horaria de la sesión al salir, mientras que DATETIME devuelve literalmente lo que escribiste. Cambia de servidor y con él time_zone, y sólo las columnas TIMESTAMP parecerán desplazarse, filas históricas incluidas. |
| Un desfase fijo se rompe con el horario de verano o un cambio legal | Un desfase como +09:00 registra la diferencia en un instante, no un lugar. JST no tiene horario de verano, así que un sistema puramente japonés rara vez lo nota, pero se desmorona en cuanto aparecen usuarios estadounidenses o europeos: Nueva York alterna entre -05:00 y -04:00 dos veces al año, de modo que una reunión semanal de los lunes a las 9 guardada en marzo con -05:00 suena a las 8 en abril. Los desfases también cambian por ley: Samoa cruzó la línea de cambio de fecha en 2011 y aquel año sencillamente no tuvo 30 de diciembre. |
Guarda los sucesos pasados como instantes (UTC) y las citas futuras como nombre de zona IANA más hora local. Cumplen funciones distintas: una entrada de registro sólo dice cuándo ocurrió algo, pero una cita es una promesa sobre las 9 de la mañana donde está la persona, así que si no conservas Asia/Tokyo o America/New_York como región, cada cambio normativo mueve la reunión. La base de datos de zonas horarias (tzdata) se actualiza varias veces al año: una imagen de contenedor fijada sigue con las reglas viejas, y por eso refrescar las imágenes base importa por motivos que van más allá de la seguridad. |
Una marca de tiempo Unix no es el número de segundos transcurridos desde 1970-01-01T00:00:00Z: es una cuenta que finge que los segundos intercalares nunca ocurrieron y que, en 2026, difiere del tiempo real transcurrido en 27 segundos. Las aplicaciones corrientes pueden ignorarlo, pero si ordenas operaciones financieras o razonas sobre causalidad en un sistema distribuido, ese segundo cuenta: al insertarse un segundo intercalar, algunos sistemas emiten la misma marca dos veces o retroceden el reloj un segundo. Google y AWS reparten el ajuste a lo largo de un día entero, de modo que ese día sus relojes quedan hasta medio segundo por detrás de los demás. Cuando necesites unicidad, no uses la marca de tiempo como clave primaria: acompáñala de un identificador monótonamente creciente.
📖 Cómo usar
-
1
Ingresa el timestamp o fechaEscribe el timestamp en segundos o milisegundos.
-
2
Revisa los resultadosSe muestran múltiples formatos. Haz clic en una fila para copiar.
-
3
Ajusta con los botones de intervaloUsa los botones para ajustar el timestamp.
❓ Preguntas frecuentes
¿Cómo se distinguen segundos de milisegundos?
¿Qué es JST?
¿Qué es un timestamp Unix?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.