Marcas de tiempo Unix: segundos, milisegundos y fechas incorrectas
Cuatro entradas, un mismo instante. Descubre por qué una marca puede acabar en 1970 o en otro día.
Una marca de tiempo que cae en enero de 1970 a menudo tiene la unidad incorrecta. El número 1792069200 son segundos Unix; 1792069200000 es el mismo instante en milisegundos. Ninguno requiere que agregues un desfase de zona horaria antes de convertirlo.
Abre el Conversor de zonas horarias, expande Pegar una fecha o marca de tiempo, pega cualquiera de los dos números y elige Convertir. Revisa la interpretación debajo del formulario. Ambos deberían producir 2026-10-15T13:00:00.000Z.
Cuatro formas de escribir el mismo momento
Prueba estas una a la vez, o descarga los cuatro ejemplos de marcas de tiempo:
1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00
La última línea ya es medianoche del día siguiente, pero sigue representando el mismo momento. Su desfase explícito de once horas explica la diferencia.
La herramienta lee el primer número como segundos y el segundo como milisegundos. Para fechas cercanas a hoy, 10 frente a 13 dígitos es una pista útil, no una definición universal de marca de tiempo. Este conversor rechaza entradas numéricas de 11 y 12 dígitos en lugar de adivinar. Admite fechas desde 1900 hasta 2100; no es un analizador para cada formato histórico de marca de tiempo.
Si escribes JavaScript, el constructor numérico Date espera milisegundos. La referencia de Date de MDN documenta esa unidad. Multiplicar segundos por 1,000 es una conversión de unidades, no un ajuste de zona horaria.
Revisa la fecha además del reloj
Usa Añadir zona para incluir las ciudades que necesites. Para el ejemplo anterior, los resultados probados son:
| Zona | Fecha y hora local | Desfase UTC en esa fecha |
|---|---|---|
| UTC | 15 de octubre de 2026, 13:00 | +00:00 |
| Australia/Melbourne | 16 de octubre de 2026, 00:00 | +11:00 |
| Europa/Londres | 15 de octubre de 2026, 14:00 | +01:00 |
| América/Nueva_York | 15 de octubre de 2026, 09:00 | -04:00 |
Estos desfases pertenecen a la fecha de ejemplo. No los reutilices como diferencias permanentes entre ciudades; el horario de verano puede cambiar la brecha. Para una tarea recurrente, consulta el ejemplo de cron y horario de verano.
Arrastrar dentro de cualquier tarjeta de reloj mueve el momento compartido, por lo que todas las tarjetas se actualizan juntas. Copiar horas copia también las fechas y los desfases. Eso es más útil para un compañero que enviar “9am” por sí solo.
Una fecha sin desfase es una entrada diferente
Pega 2026-10-15T13:00 y establece Sin zona horaria, interpretar como en Australia/Melbourne. Se convierte en 2026-10-15T02:00:00.000Z, once horas antes que nuestro primer ejemplo.
Nada se rompió: esta vez proporcionaste una lectura de reloj local, y la zona horaria de origen suministró el contexto faltante. Con un número Unix o un desfase explícito, esa selección de origen no mueve el instante. Mi zona puede agregar la zona de tu dispositivo, pero tu dispositivo no puede decirte qué zona horaria usó originalmente una entrada de registro sin etiqueta.
Resuelve entradas ambiguas antes de compartirlas
La herramienta te pide deliberadamente que aclares varias entradas:
10/11/2026 09:00podría significar 11 de octubre o 10 de noviembre. Usa una fecha año-mes-día.2026-10-15 09:00 CSTusa una abreviatura ambigua. Elige una zona horaria de origen completa o proporciona un desfase UTC explícito.2026-11-01T01:30enAmerica/New_Yorkocurre dos veces cuando los relojes retroceden. Proporciona el desfase previsto; una lectura de reloj local por sí sola no puede elegir entre ellos.
Verificamos estas entradas y las cuatro marcas de tiempo equivalentes contra el analizador de la herramienta el 15 de octubre de 2026. La salida de conversión y el registro de resultados conservan los valores exactos. El análisis en lenguaje natural varía según el idioma; una fecha y un desfase explícitos son la mejor opción cuando el tiempo debe ser inequívoco.