Milisegundos a fecha: UTC vs hora local, y por que puede parecer incorrecto

Ultima revision 2026-05-05. El conversor gratis de milisegundos a fecha toma un timestamp Unix en milisegundos y devuelve una fecha y hora legibles. La mayor parte de la confusion del lector no es sobre la conversion en si - es sobre que zona horaria representa la cadena legible. Esta guia nombra los cuatro valores que siempre debes leer juntos y da una verificacion de cordura de 30 segundos para que nunca envies una fecha que este horas equivocada.

Por que el mismo timestamp muestra fechas diferentes

Un timestamp Unix en milisegundos cuenta los milisegundos transcurridos desde el epoch Unix, fijo en 1970-01-01T00:00:00 UTC. El numero no lleva una zona horaria o un calendario. Cada sistema que lo muestra elige su propia zona para la salida legible: tu navegador usa el locale del SO, un servidor usa el locale de su contenedor, una base SQL usa la zona horaria de la sesion, y un log JSON usa lo que el escritor formateo. El conversor de milisegundos a fecha muestra tanto UTC como tu hora local para que puedas ver el offset de un vistazo.

Los cuatro valores para leer siempre juntos

• El numero original (1713538800000) - sin zona horaria. Almacenalo en bases de datos, envialo por APIs HTTP, registralo en logs. Nunca se desvia.
• Fecha/hora UTC (2024-04-19T15:00:00Z) - la renderizacion canonica. Usala en logs de auditoria, informes entre regiones, y cualquier cosa compartida entre equipos.
• Fecha/hora local (2024-04-19 22:00:00 +07:00) - lo que ve el usuario final. Usala para correos, invitaciones de calendario, y pantallas para el lector.
• ISO 8601 con offset (2024-04-19T22:00:00+07:00) - seguro para ida y vuelta. Incluye reloj y offset, asi un parser downstream puede recuperar el momento exacto.

Verificacion de cordura de 30 segundos antes de enviar una fecha

1. Confirma que la entrada esta en milisegundos, no en segundos. Un numero de 13 digitos es milisegundos; un numero de 10 digitos es segundos. Ver numero largo - milisegundo o segundo? para las reglas.
2. Anota el valor UTC que el conversor devuelve. Esta es la respuesta canonica y sin zona.
3. Suma el offset local al UTC (ej. +07:00 para Bangkok, -08:00 para Los Angeles, con horario de verano). El valor local debe coincidir.
4. Si el valor local discrepa, la zona del SO esta configurada distinta de lo que asumiste. Ajusta el SO o interpreta el UTC directamente.

UTC vs local en la practica

Usa UTC para almacenamiento y transporte. Columnas de bases de datos, JSON sobre HTTP, archivos de log, registros de auditoria. Los valores UTC no se desvian a traves de transiciones de horario de verano y no varian por region de despliegue.

Usa hora local solo para visualizacion. Invitaciones de calendario, correos de usuario, recordatorios. Convierte a local en la capa de renderizacion, no en el almacenamiento. La misma fila de la base debe renderizar como 22:00 hora de Bangkok y 08:00 hora de LA - eso es correcto, no es un bug.

Usa ISO 8601 con offset para los casos intermedios. Cuando envias un valor a un sistema downstream que puede no conocer la zona del usuario, prefiere la forma ISO con offset incluido. Evita texto libre "19 de abril a las 22h" - no es parseable.

Guias complementarias

• Numero largo - milisegundo o segundo? - desambiguacion de entrada.
• Timestamps Unix explicados - que es el epoch y de donde viene el formato.
• Conversor de milisegundos a fecha - la herramienta en si.
• Obtener hora actual en milisegundos - la direccion inversa.

Preguntas frecuentes

Por que el conversor muestra dos horas distintas para la misma entrada?

Son el mismo instante en zonas horarias distintas. El numero es sin zona; el valor UTC es la renderizacion canonica y el valor local es el mismo instante visto desde la zona del SO. La diferencia es el offset local.

La hora local se ve mal - como la arreglo?

La hora local es lo que sea que tu SO reporte como la zona actual. Si tu portatil esta configurado a Singapur pero esperas Bangkok, el valor local estara una hora mal. Ajusta la zona del SO, o interpreta el valor UTC y aplica el offset que realmente quieres.

El horario de verano cambia la conversion?

Si - para cualquier zona que observa horario de verano, el offset local cambia una hora dos veces al ano. El valor UTC nunca cambia. Dos timestamps de lados opuestos de un cambio de horario de verano se ven una hora aparte en hora local incluso cuando los milisegundos transcurridos son correctos.

Puedo guardar hora local directamente en mi base de datos?

Si, pero rara vez es buena idea. Almacenar UTC y renderizar local en el sitio de lectura es canonico; sobrevive a movimientos de servidor, cambios de region y transiciones de horario de verano. Almacenar hora local obliga a cada lector a saber en que zona estaba el escritor - generalmente perdido.

Se envia algo a un servidor?

La conversion se ejecuta en tu navegador; la entrada en milisegundos y las cadenas resultantes se quedan en tu dispositivo. Esto importa cuando el timestamp identifica un evento sensible que no quieres registrar.