Saltar al contenido principal
CalcMax

Calculadora de zona horaria

Resultado

23:00:00

Hora en el destino

Fecha en el destino
14 de enero de 2026
Día de la semana en el destino
miércoles
Desfase UTC de origen
UTC+08:00
Desfase UTC de destino
UTC-05:00
Diferencia con el origen
-13,00 horas
Cambio de día
-1

La calculadora de zona horaria convierte una fecha y una hora de una zona horaria a otra e informa de cómo se ve ese momento al otro lado: la hora local, la fecha, el día de la semana y si has caído en el día anterior o en el siguiente. Los dos desfases UTC se imprimen junto al resultado, así que la diferencia horaria entre dos ciudades es un número que se lee en lugar de uno que hay que deducir, y las reglas de horario de verano vigentes en esa fecha exacta vienen ya aplicadas. Es lo que necesitas antes de fijar una reunión entre zonas horarias, antes de preguntar qué día es allí, o cuando llega una hora de otro país y hay que colocarla en tu propio calendario. El salto de día es la parte que se calcula mal a mano, porque no es una propiedad fija del par de ciudades: las mismas dos zonas se llevan 13 horas en enero y 12 en julio. Y hay un detalle que se pasa por alto con facilidad: cuando hay un cambio de horario de verano existen horas locales que no ocurren nunca —cuando el reloj se adelanta— y horas que ocurren dos veces —cuando se atrasa—. La página no rechaza ninguna de las dos: la hora inexistente se desplaza hacia delante y, de las dos lecturas posibles, toma la primera. Nunca da error, así que en las fechas cercanas a un cambio conviene mirar los desfases impresos.

Fórmula

hora local de destino = hora local de origen − desfase UTC de origen + desfase UTC de destino; diferencia de desfase = desfase de destino − desfase de origen; salto de día = fecha de destino − fecha de origen

date
El día del calendario en origen, escrito como AAAA-MM-DD. Es el día de allí, no el día donde estás leyendo esto
time
La hora local en origen, como HH:MM o HH:MM:SS en formato de 24 horas. Los segundos se pueden omitir; en el resultado aparecen siempre
fromZone
La zona horaria a la que pertenece la hora que escribiste. Una de 22 zonas IANA, cada una etiquetada con su ciudad y no con su desfase, porque el desfase es una propiedad del momento y no del lugar
toZone
La zona horaria a la que quieres convertir. Las mismas 22 zonas de la lista de origen
toTime
La hora local en la zona de destino, siempre con segundos. Es el resultado principal
toDate
La fecha en la zona de destino, que no siempre es la que escribiste: de eso va justamente el salto de día
toWeekday
El día de la semana en la zona de destino, como número de 0 (domingo) a 6 (sábado)
fromOffset
Cuánto se separa la zona de origen de UTC en el instante resultante, escrito como UTC±HH:MM
toOffset
Cuánto se separa la zona de destino de UTC en ese mismo instante. Los dos desfases se leen en el momento convertido, así que ambos incluyen el horario de verano si está en vigor allí
offsetDifference
El desfase de destino menos el de origen, en horas. Un valor negativo significa que el destino va por detrás del origen
dayShift
−1, 0 o +1: si la fecha de destino es el día anterior, el mismo día o el siguiente al que escribiste

Úsala siempre que haya dos lugares de por medio y haya que fiarse de un reloj: reservar una llamada al otro lado de un océano, comprobar si un vuelo aterriza el mismo día en que despegó, leer un registro de servidor escrito en UTC o entender por qué el «domingo por la mañana» de alguien es tu domingo por la tarde. Esta página convierte un instante que ya tienes; no dice en qué zona horaria está un lugar —las listas son fijas, 22 zonas— y no sabe nada de tiempos de viaje, duraciones de vuelo ni recordatorios de citas.

Ejemplos resueltos

  1. Mediodía en Shanghái → Nueva York: el día anterior

    1. Shanghái está en UTC+08:00 en enero, así que el mediodía de allí son las 04:00 UTC del 15 de enero
    2. Nueva York está en EST, UTC−05:00, así que las 04:00 UTC se leen como las 23:00 en el reloj de allí
    3. Las 23:00 están antes de la medianoche, lo que coloca la fecha en el 14 de enero: un día antes del que escribiste, y el salto de día lo indica con −1
    4. El 14 de enero de 2026 es miércoles, así que el número del día de la semana es 3
    5. Los dos desfases se llevan 13 horas: de +08:00 a −05:00 hay 13 horas, y el destino es el que está más al oeste

    Es el estado con el que se abre la calculadora y el caso que más sorprende: un mensaje enviado a la hora de comer en Shanghái llega a Nueva York en el día natural anterior. Hacerlo a mano con una regla del tipo «Shanghái va 12 o 13 horas por delante» es donde se cuela el error: aquí la respuesta es 13, pero en julio sería 12, porque Nueva York está en horario de verano y Shanghái no.

  2. Una hora local que no existe: Nueva York, 8 de marzo de 2026, 02:30

    1. Los relojes de Nueva York se adelantan a las 02:00 locales de esta fecha, así que las 02:00 pasan a ser las 03:00 y la media hora que va de las 02:00 a las 03:00 no ocurre nunca
    2. Las 02:30 que escribiste, por tanto, no existen. La página las lee como prescriben las reglas IANA para un hueco: las desplaza hacia delante, lo que da las 03:30 EDT
    3. Las 03:30 del 8 de marzo de 2026 caen en domingo, de ahí el día de la semana 0
    4. Como el instante resultante ya está en EDT, el desfase de origen que se imprime es UTC−04:00, y no el UTC−05:00 que habrían llevado las 02:30 el día anterior
    5. Shanghái está en UTC+08:00, doce horas por delante de EDT, así que las 03:30 son las 15:30 del mismo día

    El desfase impreso junto a una hora escrita puede parecer equivocado hasta que se ve por qué: las 02:30 en Nueva York son una lectura de UTC−05:00 en invierno, pero estas 02:30 concretas caen en el hueco posterior al cambio, así que el instante al que se resuelven es un instante EDT e informa UTC−04:00. La página lee los huecos y las repeticiones como manda la base de datos de zonas horarias de IANA, y nunca rechaza la entrada: el número sale siempre, y este es el caso que merece una segunda lectura.

  3. Los dos extremos en horario de verano: Londres → Los Ángeles el 4 de julio

    1. En julio Londres va en BST, UTC+01:00, así que las 09:30 de allí son las 08:30 UTC
    2. Los Ángeles va en PDT, UTC−07:00, así que las 08:30 UTC son las 01:30 en el reloj de allí
    3. Los desfases se llevan 8 horas, las mismas que en invierno pero compuestas de otra manera: en enero Londres es UTC+00:00 y Los Ángeles UTC−08:00, así que la diferencia coincide y el camino no
    4. Los dos desfases impresos incluyen su horario de verano, y por eso el de origen marca UTC+01:00 y no UTC+00:00
    5. La fecha no cambia, así que el salto de día es 0; y el 4 de julio de 2026 cae en sábado, día de la semana 6

    Responder esto con los desfases estándar (0 y −08:00) da la misma diferencia de 8 horas y la misma hora, y esa es exactamente la razón de que aquí el error sea fácil de no ver y aparezca en las fechas a un lado y a otro de un cambio. La semana de marzo en la que las dos zonas cambian en sentidos opuestos es cuando una regla de desfase fijo se equivoca por una hora entera.

  4. Año nuevo en Auckland, todavía el año pasado en UTC

    1. Auckland va en NZDT en enero, UTC+13:00, así que la medianoche de allí son las 11:00 UTC del 31 de diciembre de 2025
    2. Convertir a UTC cruza por tanto una frontera de día y una de año a la vez
    3. La fecha de destino es el 31 de diciembre de 2025, y el salto de día de −1 se obtiene restando números de día, no comparando cadenas de fecha
    4. El 31 de diciembre de 2025 es miércoles, día de la semana 3
    5. La diferencia de desfase es −13 horas: el destino, UTC, es el que está más al oeste

    El salto de día no es simplemente «al oeste es ayer». Aquí −13 horas cruzan la medianoche; las mismas −13 horas entre Shanghái y Nueva York también caen en el día anterior, mientras que una diferencia de −5 horas de Londres a Nueva York no lo hace. El día de la semana se informa para la fecha de destino, y por eso dice miércoles cuando la fecha escrita era un jueves.

Limitaciones

La calculadora cubre de 1970 a 2100 y 22 zonas horarias, no todas las que conoce la base de datos IANA. El intervalo es deliberado: antes de 1970 los registros guardan la hora media local que un lugar mantenía de verdad —Shanghái era UTC+08:06 y Monrovia usaba un desfase con segundos—, y respuestas así son correctas pero se leen como un fallo. Las horas locales ambiguas y las inexistentes se resuelven como prescriben las reglas IANA (hacia delante en un hueco de primavera, la primera de las dos lecturas en una repetición de otoño) en lugar de rechazarse, y la página no avisa de que ha ocurrido, así que las fechas cercanas a un cambio merecen comprobarse contra los desfases mostrados. Ninguna zona se deduce del nombre del lugar, porque no hay nada que escribir: las dos listas son fijas. La página no sabe en qué zona horaria está tu dispositivo, no calcula duraciones ni tiempos de vuelo y no incluye segundos intercalares: UTC no tiene, lo cual es distinto de los segundos intercalares que sí se le añaden a UTC.

Preguntas frecuentes

¿Cuál es la diferencia horaria entre dos ciudades?
La diferencia horaria entre dos ciudades no es un número fijo, y la que imprime esta página es la que está en vigor en la fecha que escribiste. Dos zonas pueden llevarse 13 horas en enero y 12 en julio, porque una de las dos observa el horario de verano y la otra no. Así que la pregunta «cuánto se llevan Shanghái y Nueva York» hay que hacérsela con una fecha al lado, y por eso la fecha es aquí parte de la pregunta y no un extra opcional.
¿Cómo calculo una reunión entre zonas horarias?
Pon la reunión en la zona horaria en la que se propuso y conviértela después a cada otra zona. Para una reunión entre zonas horarias el número útil suele ser el salto de día y no la hora: una llamada a las 09:00 en Londres son las 18:00 en Tokio el mismo día, pero las 04:00 en Nueva York, y esas 04:00 son las que deciden si la invitación es razonable. Como la página informa también del día de la semana y de la fecha, ves cuándo una propuesta ha caído en el fin de semana del otro lado.
¿Se aplica el horario de verano automáticamente?
Sí, en las dos zonas y para la fecha exacta, no para hoy. El horario de verano no es una propiedad de una zona horaria sino de un momento: los desfases impresos son los que las reglas IANA dan para el instante que se está convirtiendo, así que una fecha de enero y una de julio entre las mismas dos zonas pueden salir con una hora de diferencia. No se supone nada sobre la fecha actual, lo que significa que un resultado calculado para el próximo marzo ya incluye el cambio del próximo marzo.
¿Por qué el desfase UTC no es siempre el que esperaba?
Porque el desfase que se muestra pertenece al instante al que se resolvió la entrada, y no a la hora local que escribiste. El día en que los relojes se adelantan, la hora que se saltó no existe, y una hora escrita dentro de ese hueco se lee como el momento inmediatamente posterior, de modo que un 02:30 introducido para Nueva York en el día del cambio de marzo informa UTC−04:00 (EDT) y no el UTC−05:00 que llevaba ese mismo 02:30 el día anterior. Las dos lecturas son del mismo instante; solo una de ellas es el desfase vigente entonces.
¿Qué día es allí cuando aquí es miércoles?
Depende también de la hora, y por eso esta página pide las dos cosas. Si cruzas la línea de cambio de fecha hacia el este ganas un día; si conviertes hacia el oeste las horas suficientes, pierdes uno. El campo del salto de día lo responde directamente con −1, 0 o +1, y el campo del día de la semana nombra el día en el destino, así que puedes saber si al otro lado ya han llegado al día por el que preguntas.

Referencias

Calculadoras relacionadas

Calculadora de marca de tiempo UnixConvierte entre una marca de tiempo Unix y una fecha.Calculadora de fase lunarFase lunar e iluminación para cualquier fecha.Calculadora de tiempo restanteCuánto falta para una fecha, en todas las unidades.Calculadora de calendarioUn mes de un vistazo y qué día de la semana cae una fecha.