¿Por qué ‘America/New_York’ es mejor que ‘GMT-5’?

Porque America/New_York es una regla, no un valor. Codifica EST, EDT y las fechas de transición entre ellos — actualmente el segundo domingo de marzo y el primer domingo de noviembre. ‘GMT-5’ solo es correcto durante la mitad del año. Cualquier sistema que use offsets fijos falla silenciosamente cada primavera y otoño.

¿Por qué los relojes de EE. UU. y Europa no cambian el mismo fin de semana?

EE. UU. pasa al horario de verano el segundo domingo de marzo; la UE lo hace el último domingo de marzo. Normalmente hay una ventana de una a tres semanas en que el offset EE. UU./UE es una hora menor de lo usual. Una reunión de las 9am en Nueva York que normalmente llega a las 3pm en París cae a las 2pm durante esa ventana. Las invitaciones de calendario recurrentes no tienen esto en cuenta a menos que se crearan en un sistema consciente de zonas horarias.

¿Cuál es la mejor ventana de superposición para EE. UU. Este y Europa Occidental?

13:00–17:00 UTC funciona todo el año. Eso es aproximadamente 9am–1pm en Nueva York y 2pm–6pm en Londres (3pm–7pm CET). Evite la primera hora después de que termine la jornada laboral europea — el compromiso cae bruscamente.

¿Existe alguna superposición que incluya EE. UU. Oeste y Asia?

Apenas. La hora del Pacífico y Tokio se superponen durante aproximadamente una hora por la mañana del Pacífico / tarde de Tokio (7am PT = 11pm JST en invierno, medianoche en verano). La mayoría de los equipos distribuidos globalmente aceptan que este emparejamiento es solo asíncrono o rota la incomodidad.

¿Por qué Outlook y Google Calendar no coinciden en la misma invitación?

Los archivos ICS pueden codificar una reunión con un instante UTC fijo más una zona de visualización, o con una hora ‘flotante’ local. Outlook históricamente usaba un enfoque, Google el otro. Cuando los clientes del remitente y receptor interpretan el campo de forma diferente, la reunión se desplaza por el offset de zona horaria. Use siempre un cliente consciente de zonas horarias y verifique que el ICS contenga un TZID.

¿Debería usar UTC para toda la programación interna?

Sí para el almacenamiento, no para la visualización. Almacene cada evento como un instante UTC más la zona IANA del originador. Muestre en la zona local de cada espectador. Nunca programe una reunión recurrente con ‘UTC’ como zona de visualización — no cambia para el horario de verano, por lo que la reunión se desviará una hora dos veces al año para la mayoría de los asistentes.

Guide

Programar reuniones en diferentes zonas horarias: guía práctica para equipos remotos

La reunión recurrente en su calendario está mal dos veces al año, de dos formas diferentes, y nadie se lo dijo.

By Buğra SözeriPublished May 31, 2026

Los equipos distribuidos pierden una cantidad absurda de tiempo con los mismos pocos errores de zona horaria: reuniones que se desplazan una hora dos veces al año, invitaciones de calendario que llegan a la hora incorrecta, “las 9am para todos” que no lo es. Las correcciones son pequeñas. El costo de no aplicarlas es un lanzamiento de producto perdido por año, como promedio.

Use zonas IANA, no offsets fijos

La Base de Datos de Zonas Horarias IANA (a menudo llamada tzdata o zoneinfo) es la fuente canónica de cómo se comportan los relojes en todo el mundo. Cada zona — Europe/Istanbul, America/Los_Angeles, Asia/Tokyo — es una regla: el historial completo de offsets UTC, transiciones de horario de verano y cambios políticos para esa ubicación.

Un offset simple como GMT+3 o UTC-5 es un valor. Sucede que es correcto para algunos lugares en algunas épocas del año, pero no sabe sobre el horario de verano ni sobre ningún cambio legal futuro. Türkiye eliminó el horario de verano en 2016 y se movió permanentemente a UTC+3; el Reino Unido permanece en UTC+0 en invierno y UTC+1 en verano. Un sistema con offsets fijos se equivoca silenciosamente.

Regla general: cada datetime almacenado en su base de datos debe viajar con un ID de zona IANA junto al instante UTC. La zona le dice cómo mostrarlo; el instante le dice cuándo ocurrió realmente. Nuestra entrada del glosario de zona horaria IANA cubre el formato con más profundidad.

Semanas de transición del horario de verano

La forma más confiable de encontrar errores de zona horaria en una aplicación de calendario es mirar la segunda semana de marzo. He aquí el motivo.

Estados Unidos cambia al horario de verano el segundo domingo de marzo y vuelve el primer domingo de noviembre (desde 2007).
Unión Europea cambia el último domingo de marzo y vuelve el último domingo de octubre.
Reino Unido sigue el calendario de la UE (BST comienza el último domingo de marzo).
Australia (estados orientales) cambia en la dirección opuesta en octubre y abril — están en el hemisferio sur.
Japón, China, India, la mayor parte de África, la mayor parte de América del Sur — sin horario de verano.

La consecuencia práctica: entre el segundo domingo de marzo y el último domingo de marzo, EE. UU. está en horario de verano mientras Europa aún está en horario estándar. La brecha habitual de Nueva York / Londres de 5 horas se reduce a 4. Una reunión de las 9am en Nueva York que normalmente llega a las 2pm en Londres llega a la 1pm. Las reuniones recurrentes almacenadas como “9am America/New_York” en un cliente consciente de zonas horarias manejan esto correctamente. Las almacenadas como “14:00 UTC” no lo hacen.

Ventanas de superposición prácticas

Para equipos distribuidos globalmente, la pregunta no es “qué hora funciona” — es “qué ventana funciona durante todo el año, incluyendo las semanas de transición del horario de verano.” Estas son las que sobreviven:

EE. UU. Este ↔ Europa Occidental

13:00–17:00 UTC. Eso es aproximadamente 9am–1pm del Este y 2pm–6pm en Londres / 3pm–7pm en Europa Central. Ambos lados están claramente en la jornada laboral, y el desajuste del horario de verano solo desplaza la reunión una hora antes en hora local para los europeos durante las semanas de transición.

EE. UU. Oeste ↔ Europa Occidental

16:00–17:00 UTC. Una ventana de una hora: 9am Pacífico = 5pm Londres. Cualquier cosa anterior pierde a los europeos; cualquier cosa posterior pierde al Pacífico. Muchos equipos aceptan esto y realizan una sincronización semanal única, con todo lo demás de forma asíncrona.

Europa Occidental ↔ Asia (Tokio, Singapur, Seúl)

08:00–10:00 UTC. 9am Londres = 6pm Tokio. Temprano para Londres, fin de día para Tokio. Mueva las reuniones recurrentes a lunes o martes para que ninguno de los dos lados esté abriendo o cerrando la semana.

EE. UU. Oeste ↔ Asia

14:00–15:00 UTC. Eso es 7am Pacífico = 11pm Tokio (invierno). Doloroso para ambos lados. La mayoría de los equipos que emparejan estas dos regiones omiten las reuniones en directo por completo y rotan la carga cuando el tiempo síncrono es inevitable.

Para búsqueda interactiva, nuestro planificador de reuniones muestra bandas de superposición entre múltiples zonas. El reloj mundial es bueno para verificaciones rápidas de “¿es de madrugada para ellos ahora mismo?”

Trampas de las invitaciones de calendario

ICS sin TZID

El formato iCalendar (ICS) que hablan todas las principales aplicaciones de calendario puede codificar una reunión de dos formas: como un instante UTC (p. ej., DTSTART:20260601T130000Z) o como una hora local vinculada a una zona (p. ej., DTSTART;TZID=America/New_York:20260601T090000). La primera forma no es ambigua sobre el instante pero no cambia con el horario de verano. La segunda sí cambia, porque el cliente del receptor consulta la regla actual para la zona nombrada.

Las reuniones recurrentes siempre deben usar la forma TZID. Si crea un evento recurrente en una herramienta que almacena solo UTC, todos los asistentes fuera de esa zona verán la reunión desplazarse una hora dos veces al año.

Interpretación de Outlook vs Google

Históricamente, Outlook respetaba la zona horaria del originador para la visualización mientras Google convertía a la zona del espectador. Los comportamientos han convergido, pero las reuniones heredadas pueden aparecer una hora desviadas. Cuando un destinatario reporta la hora incorrecta, lo primero que debe verificar es si el ICS contiene una línea TZID.

Horas “flotantes”

Algunas aplicaciones admiten una tercera forma: hora local sinningunazona, lo que significa “9am donde estés.” Esto es correcto para recordatorios de “tome su medicación a las 9am” y casi siempre incorrecto para reuniones compartidas. Evítelo para la programación de equipos.

Recomendaciones prácticas

Almacene UTC + zona IANA. Dos columnas: una para el instante absoluto, una para la zona del originador. Muestre en la zona del espectador.
Elija los tiempos de las reuniones recurrentes por banda UTC, no por hora local.Un semanal de “13:00 UTC” permanece en la misma ventana de superposición todo el año aunque se desplace una hora en reloj local.
Audite las reuniones recurrentes alrededor de las transiciones del horario de verano. Reserve 30 minutos la semana antes de cada transición para confirmar que las invitaciones de calendario aún llegan donde se esperaba.
Predetermine lo asíncrono. La solución más barata para la zona horaria son menos reuniones de asistencia obligatoria.
Use nombres de zona IANA en las herramientas. “PST” es ambiguo (Pakistán vs Pacífico vs Pitcairn).America/Los_Angeles no lo es.

Pruebe el planificador

Ingrese las zonas de su equipo en nuestro planificador de reuniones para ver bandas de superposición verde/rojo a lo largo de un día de 24 horas. Para conversiones puntuales, el conversor de zona horaria maneja entradas arbitrarias de fecha y hora.

Conclusión

Los errores de zona horaria son completamente prevenibles. Use nombres de zona IANA, almacene UTC más zona, programe reuniones recurrentes por banda UTC y verifique alrededor de las semanas de transición del horario de verano. La mayor parte de la frustración relacionada con el calendario en los equipos distribuidos se debe a que se viola una de esas cuatro reglas. Son baratas de seguir; la alternativa son reuniones perdidas y resentimiento silencioso.

Frequently asked questions

¿Por qué ‘America/New_York’ es mejor que ‘GMT-5’?: Porque America/New_York es una regla, no un valor. Codifica EST, EDT y las fechas de transición entre ellos — actualmente el segundo domingo de marzo y el primer domingo de noviembre. ‘GMT-5’ solo es correcto durante la mitad del año. Cualquier sistema que use offsets fijos falla silenciosamente cada primavera y otoño.
¿Por qué los relojes de EE. UU. y Europa no cambian el mismo fin de semana?: EE. UU. pasa al horario de verano el segundo domingo de marzo; la UE lo hace el último domingo de marzo. Normalmente hay una ventana de una a tres semanas en que el offset EE. UU./UE es una hora menor de lo usual. Una reunión de las 9am en Nueva York que normalmente llega a las 3pm en París cae a las 2pm durante esa ventana. Las invitaciones de calendario recurrentes no tienen esto en cuenta a menos que se crearan en un sistema consciente de zonas horarias.
¿Cuál es la mejor ventana de superposición para EE. UU. Este y Europa Occidental?: 13:00–17:00 UTC funciona todo el año. Eso es aproximadamente 9am–1pm en Nueva York y 2pm–6pm en Londres (3pm–7pm CET). Evite la primera hora después de que termine la jornada laboral europea — el compromiso cae bruscamente.
¿Existe alguna superposición que incluya EE. UU. Oeste y Asia?: Apenas. La hora del Pacífico y Tokio se superponen durante aproximadamente una hora por la mañana del Pacífico / tarde de Tokio (7am PT = 11pm JST en invierno, medianoche en verano). La mayoría de los equipos distribuidos globalmente aceptan que este emparejamiento es solo asíncrono o rota la incomodidad.
¿Por qué Outlook y Google Calendar no coinciden en la misma invitación?: Los archivos ICS pueden codificar una reunión con un instante UTC fijo más una zona de visualización, o con una hora ‘flotante’ local. Outlook históricamente usaba un enfoque, Google el otro. Cuando los clientes del remitente y receptor interpretan el campo de forma diferente, la reunión se desplaza por el offset de zona horaria. Use siempre un cliente consciente de zonas horarias y verifique que el ICS contenga un TZID.
¿Debería usar UTC para toda la programación interna?: Sí para el almacenamiento, no para la visualización. Almacene cada evento como un instante UTC más la zona IANA del originador. Muestre en la zona local de cada espectador. Nunca programe una reunión recurrente con ‘UTC’ como zona de visualización — no cambia para el horario de verano, por lo que la reunión se desviará una hora dos veces al año para la mayoría de los asistentes.

Published May 31, 2026