Elige la hora en una zona con nombre, la de la que depende la reunión, como Europe/Madrid, y comprueba la fecha contra las reglas de horario de verano de esa zona en lugar de contra el desfase de hoy. Después escribe la invitación con el día de la semana, la fecha, la hora y la ciudad, más la hora en UTC como comprobación. La mayoría de las reuniones a la hora equivocada vienen de convertir con un desfase que era cierto cuando alguien hizo la cuenta y ya no lo es el día de la reunión.
¿Por qué una conversión que estaba bien el mes pasado sale una hora desfasada?
Porque la diferencia entre dos ciudades no es constante. El desfase de cada ciudad cambia según su propio calendario, y los calendarios no coinciden. Si calculaste "Nueva York está seis horas detrás de Madrid" en verano y lo aplicaste a una reunión de noviembre, usabas un número con fecha de caducidad. La diferencia entre una zona horaria y un desfase lo explica: la zona es la regla, el desfase es una lectura de esa regla.
Para una reunión que aún no ha ocurrido, el nombre de la zona es el punto de partida de la conversión. El desfase es algo que se consulta para esa fecha concreta.
¿Cuándo no coinciden EE. UU. y Europa en la hora?
Los dos cambian dos veces al año, en fechas distintas. En Estados Unidos los relojes se adelantan el segundo domingo de marzo y se atrasan el primer domingo de noviembre, a las 02:00 hora local. En la Unión Europea se adelantan el último domingo de marzo y se atrasan el último domingo de octubre, ambos a la 01:00 UTC. La UE debate desde 2018 acabar con el cambio y, según el debate del Parlamento Europeo de octubre de 2025, no ha decidido; la propuesta aún necesita el acuerdo del Consejo y del Parlamento. Comprueba antes de dar por hecho que la regla se mantiene para una fecha de dentro de varios años.
Para 2026 eso deja dos tramos en los que la diferencia habitual es incorrecta:
- Del 8 al 29 de marzo: Nueva York ya está en
-04:00, Madrid sigue en+01:00. La diferencia es de cinco horas, no de seis. - Del 25 de octubre al 1 de noviembre: Madrid ha vuelto a
+01:00, Nueva York sigue en-04:00. Otra vez cinco horas.
Son unas cuatro semanas de cincuenta y dos en las que la regla de "seis horas" falla, y caen justo donde más se agenda: el cierre de un trimestre, el inicio de un sprint. Las fechas cambian cada año porque las reglas dicen "el enésimo domingo", así que no las copies en una plantilla. Búscalas para el año de la reunión.
Otros lugares añaden sus propios calendarios. Las zonas del hemisferio sur que aplican horario de verano, como Nueva Zelanda, cambian en la estación opuesta. Muchos lugares no cambian nunca: America/Argentina/Buenos_Aires se queda en -03:00 y Asia/Kolkata en +05:30. Por eso la diferencia entre Madrid y Buenos Aires es de cuatro horas en invierno y de cinco en verano, porque solo se mueve uno de los dos lados.
¿A qué zona hay que anclar la reunión?
A la de las personas o el lugar que definen la reunión. Una llamada semanal de equipo pertenece a la zona de origen del equipo. Un webinar pertenece a la del anfitrión. La apertura de una tienda o un vuelo pertenecen al lugar donde ocurren. Todos los demás son una conversión de esa.
Anclar importa sobre todo en reuniones recurrentes. Si la regla es "cada lunes a las 09:00 de Madrid", los colegas de Nueva York verán que se mueve una hora en su calendario durante los tramos de arriba, y no hay ningún error: el reloj de Madrid se quedó quieto y el suyo se movió. Si en cambio la anclas a Nueva York, el cambio lo ve Madrid. Decide qué lado absorbe el cambio y dilo en la invitación; si no, quienes lo sufran supondrán que hubo un error.
En una reunión única, haz la conversión una sola vez, para la fecha real y no para hoy.
¿Cómo se escribe una invitación que no se pueda malinterpretar?
Da al lector lo suficiente para que un fallo en cualquier parte se note frente a las demás:
- El día de la semana y la fecha completa, con el mes escrito. "4/11" es abril en un país y noviembre en otro.
- La hora en formato de 24 horas, con la ciudad o el nombre de zona IANA al lado:
15:00 Madrid. - El mismo instante en UTC:
14:00 UTC. - Opcionalmente, una o dos horas locales de los asistentes, cuando las conozcas.
Por ejemplo: miércoles 4 de noviembre de 2026, 15:00 Madrid (14:00 UTC; 09:00 Nueva York). Tres números que concuerdan son difíciles de malinterpretar, y cuando no concuerdan alguien lo nota.
No uses abreviaturas de tres letras como única etiqueta. CST es la hora estándar central de EE. UU., la de China y la de Cuba, e IST la reclaman India, Irlanda e Israel. Un nombre de ciudad es inequívoco de una forma en que una abreviatura no lo es. Y no escribas "tu hora" sin decir de quién.
¿Y las reuniones que cruzan la medianoche?
La fecha cambia junto con la hora. La misma reunión, a las 14:00 UTC del miércoles 4 de noviembre de 2026, es a las 03:00 del jueves en Auckland, que está en +13:00. Quien esté en esa zona y lea "miércoles" llegará un día antes o concluirá que no es para esa persona. Cuando un asistente esté a más de unas diez horas del organizador, incluye su día de la semana local, no solo su hora local. O elige un horario que caiga en la misma fecha para todos, si existe.
¿Cómo puedes comprobar la conversión en tu navegador?
Usa el lado de fecha a timestamp del conversor de timestamps Unix. Escribe la fecha y la hora de la reunión, pon "Interpretar como" en UTC, y el resultado muestra el mismo instante en tu hora local y en UTC. Si tu dispositivo está en una zona con una regla distinta a la de la reunión, obtienes una comprobación independiente de lo que dice el calendario. Todo se calcula en tu dispositivo y no se sube nada.
Sus límites importan aquí. No tiene selector de zonas: solo conoce UTC y la zona de tu dispositivo. No puedes preguntarle qué hora es una reunión en Madrid a menos que trabajes tú hacia atrás desde UTC, ni cuál será el desfase de Madrid en una fecha dada. Cuando la fecha que escribes cae en un día de cambio de hora, no te avisa de que una hora local se saltó o se repitió; el navegador elige una lectura sin decir nada. Escribir la hora como UTC evita esa ambigüedad, y es una razón para preferir UTC como entrada. Para un instante no hace falta ninguna zona.
¿Qué hacer cuando la reunión está cerca de un cambio de hora?
Reenviarla. Si creaste el evento antes de que se movieran los relojes, un calendario moderno lo mantiene a la hora de reloj de la zona en que se creó, así que normalmente está bien. Si lo enviaste como texto, o alguien lo copió a una hoja de cálculo como hora UTC, no lo está. Un mensaje el día anterior con los tres números otra vez cuesta menos que alguien que se pierda el comienzo. Cuando alguien diga que la hora está mal, pregunta desde qué zona convirtió antes de discutir.
Para comprobar una hora que calculaste, introdúcela como UTC en el conversor de timestamps Unix y lee el resultado local de tu propio dispositivo. Solo conoce tu zona y UTC, así que no sustituye consultar las reglas de la otra ciudad para esa fecha.
Si quieres el razonamiento detrás de anclar una reunión a una zona con nombre, una zona horaria no es un desfase explica lo que pierdes al guardar solo el número.
Preguntas frecuentes
¿Cuál es la mejor forma de agendar una reunión entre zonas horarias?
Elige la hora en una zona con nombre, normalmente la de la que depende la reunión, como Europe/Madrid. Comprueba esa fecha contra las reglas de horario de verano de cada asistente. Escribe la invitación con el día de la semana, la fecha completa, la hora y la ciudad, y la misma hora en UTC, para poder contrastar cada parte con las demás.
¿Por qué una reunión sale una hora desfasada para algunas personas solo en algunas semanas del año?
Porque cada lugar cambia sus relojes en fechas distintas. En 2026 EE. UU. cambió el 8 de marzo y la UE el 29 de marzo, así que durante tres semanas la diferencia entre Nueva York y Madrid fue de cinco horas en lugar de seis. Lo mismo ocurre en otoño, entre el cambio de la UE del 25 de octubre y el de EE. UU. del 1 de noviembre.
¿Debo enviar la hora de una reunión en UTC o en hora local?
Envía las dos. La hora local en una ciudad con nombre dice qué quiere decir el organizador, y la hora UTC permite a cualquiera comprobar la conversión. Solo UTC es correcto pero obliga a cada asistente a hacer una cuenta; solo la hora local omite la información necesaria para comprobarla.
¿Una reunión recurrente se mueve cuando cambia el horario de verano?
Se queda fija en la zona en que se creó y se mueve en el calendario de los demás cuando solo un lado cambia sus relojes. Una reunión semanal a las 09:00 de Madrid sigue a las 09:00 en Madrid, pero se desplaza una hora para Nueva York en las semanas en que solo uno de los dos ha cambiado. Di qué lado conserva la hora fija.
¿Puedo fiarme de EST, CST o IST en una invitación?
No por sí solas. CST puede significar hora estándar central de EE. UU., de China o de Cuba, e IST puede significar India, Irlanda o Israel. Usa un nombre de ciudad o un nombre IANA como America/Chicago, y trata la abreviatura como un adorno opcional para quien lo prefiera.
Última actualización 30 de octubre de 2026
