Los problemas con las zonas horarias del calendario suelen repetirse. Tú ves la reunión a las 09:00 y la persona invitada la ve a las 15:00. Esa diferencia puede ser normal, pero también puede ocurrir que las invitaciones indiquen momentos distintos. O todo funciona durante varias semanas y la reunión se desplaza una hora tras el cambio de hora. O el recordatorio llega mientras duermes.
Muchas veces el problema no está en cómo se muestra el evento. Se guardó simplemente «las 9», sin indicar en qué zona eran esas 9. Los componentes que utilizan el dato completan lo que falta por su cuenta, y no todos hacen la misma suposición.
Veamos cómo se representan las zonas horarias en un calendario, por qué un error puede tardar semanas en aparecer y qué cambia al guardar la zona junto con la hora del evento.
El problema de la hora sin zona horaria
Supongamos que el calendario guarda el inicio como 2026-09-14 09:00, sin más información. Para una reunión compartida, ese dato es ambiguo: distintos componentes pueden interpretarlo de forma diferente.
El formulario del navegador envía la hora introducida. Un cliente CalDAV añade el identificador de zona, pero si el servidor lo ignora, solo quedan los números del reloj local. Al exportar, ese valor podría etiquetarse erróneamente como UTC porque el formato espera alguna representación definida. El servicio de recordatorios, por su parte, lo compara con la hora actual en UTC.
Cuatro componentes, cuatro interpretaciones del mismo dato. Si todos utilizan UTC, el error puede pasar desapercibido. Basta incorporar a alguien de Berlín para que algunos eventos se procesen de otra manera, sin mostrar ningún aviso.
Es fácil no detectar este defecto cuando las pruebas se limitan a una sola zona. Probar con usuarios de varias regiones permite descubrirlo antes. De lo contrario, aparece al viajar, al cambiar la hora o al invitar a alguien de otra zona horaria.
Tres formas de representar la hora en el calendario
El estándar iCalendar, utilizado para intercambiar eventos entre muchos calendarios, distingue varias representaciones de fecha y hora. Para los eventos con una hora concreta, estos son los casos relevantes.| Tipo | Ejemplo | Significado | Uso adecuado |
|---|---|---|---|
| UTC | 20260914T070000Z | Un instante concreto, igual para todos | Reuniones entre personas de distintas regiones |
| Hora con zona | TZID=Europe/Berlin:20260914T090000 | 9 de la mañana en Berlín, con conversión para los demás | Un evento vinculado a su lugar de celebración |
| Hora flotante | 20260914T090000 | 9 de la mañana según el reloj local de cada usuario | Recordatorios personales que deben seguir la hora local |
La hora flotante es válida cuando ese es el comportamiento deseado. Pero un cumpleaños, por ejemplo el día 14, suele representarse como una fecha, no como una hora flotante. En una reunión compartida, las mismas horas locales pueden corresponder a instantes distintos.
Los eventos de todo el día se guardan como fechas, sin convertirlas entre zonas. Si se transforma un festivo en un instante UTC y luego se convierte a la hora local, al oeste de Greenwich podría aparecer en la tarde del día anterior. Una fecha no debe tratarse como la hora de inicio de una reunión.
Por qué el cambio de hora hace visibles los errores
Las zonas horarias serían más sencillas si su diferencia respecto a UTC fuera constante. En muchas regiones no lo es, y los cambios hacen aparecer errores que antes no se notaban.
Berlín utiliza UTC+1 en invierno y UTC+2 en verano. Si una reunión periódica se calcula a una hora UTC fija, cambiará de hora local tras la transición: el instante está bien definido, pero ya no es la reunión de las 9. Para que una serie con la zona Europe/Berlin siga siendo a las 9, las repeticiones también deben calcularse en esa zona. Guardar su nombre, por sí solo, no basta.
La situación se complica cuando participan personas de varios países. Europa y Norteamérica cambian la hora en fechas diferentes. Entre ambas transiciones, la diferencia habitual entre Londres y Nueva York cambia una hora. La duración de ese intervalo depende de la estación y del año, por lo que no conviene darla por fija. Durante ese periodo, la reunión puede cambiar de hora local para una parte sin que el calendario tenga un fallo.
Elegir otra zona predeterminada no elimina esta diferencia. «El mismo instante» y «La misma hora local» son requisitos distintos. Hay que decidir cuál debe cumplir la serie y comprobar que el cálculo de repeticiones y el intercambio con los clientes lo respetan.
Guardar UTC junto con la zona horaria
Para un evento con hora concreta, conviene guardar ambas partes: el instante UTC y la zona en la que se introdujo la hora local. En una serie periódica también importa cómo se calculan las repeticiones.
UTC permite comparar instantes, ordenar eventos y detectar solapamientos sin ambigüedad. La zona explica la hora local de origen. Sin embargo, guardar ese campo no significa que cualquier exportación conserve todas las propiedades de una serie: hay que comprobar el formato generado y cómo lo utiliza el cliente.
En la práctica:
- Al crear un evento en el correo web se envía la zona del navegador junto con la hora introducida. El servidor convierte la hora a UTC y guarda la zona. Si el navegador está configurado para Berlín, esa será la zona registrada.
- Al verlo desde otro lugar se convierte UTC a la hora local del navegador. Para la fecha del ejemplo, Berlín muestra 09:00 y San Francisco 00:00. Ambas horas indican el mismo instante; las diferencias pueden cambiar en otras épocas del año.
- Los recordatorios disponen de un instante inequívoco para hacer la comparación. La zona deja de causar esa ambigüedad, aunque la entrega sigue dependiendo del programador de tareas y de los canales de notificación.
- Al editar se muestra la hora en la zona del navegador actual, no necesariamente en la zona original del evento. Comprueba la hora y la configuración del dispositivo antes de guardar, sobre todo después de viajar.
Qué pasa con los eventos antiguos
Los eventos antiguos pueden no tener una zona guardada. No se reinterpretan automáticamente: la interfaz web mantiene su forma anterior de mostrarlos. Así se evitan desplazamientos inesperados de las citas existentes.
Es una decisión deliberada. Asignar una zona a posteriori supone adivinarla, y una suposición equivocada cambia citas sin consultar a sus participantes. Si un evento lleva dos años mostrando 14:00, una corrección automática no debería convertirlo en otra hora. Al revisarlo manualmente, averigua primero qué significaban esas 14:00.
Es posible añadir una zona a un evento antiguo al editarlo. Cuando guardas un evento con hora en el correo web, se envía la zona del navegador; comprueba antes la hora local y los ajustes del dispositivo. Cambiar solo la descripción mediante la API, sin enviar el parámetro de zona, no añade esa información. Las entradas que no se modifican conservan su comportamiento anterior.
Si una reunión periódica antigua aparece mal para participantes de otros países, verifica la hora y la zona originales y guarda la corrección. Después revisa las repeticiones antes y después del cambio de hora: volver a guardar no garantiza, por sí solo, que toda la serie se calcule correctamente.
CalDAV, ICS y otros calendarios
El calendario no debería limitarse a una interfaz web. Apple Calendar, Thunderbird y aplicaciones móviles compatibles pueden conectarse por CalDAV. Pero tener Google Calendar en el dispositivo no implica poder conectar cualquier servidor CalDAV: hay que comprobar el método de integración y su compatibilidad.
Al recibir un evento por CalDAV, el servidor utiliza el identificador de zona para guardar el instante UTC correspondiente. El documento de calendario recibido puede devolverse sin cambios; para los eventos creados en el correo web, el servidor genera valores UTC. Por tanto, no todas las respuestas utilizan la misma representación. Los eventos de todo el día se intercambian como fechas. En las series periódicas, comprueba además si este intercambio conserva la hora local de las repeticiones.
Los clientes compatibles pueden mostrar un mismo instante: por ejemplo, un evento creado en un iPhone en Berlín, editado desde el correo web en un portátil en Lisboa y abierto en Thunderbird en Nueva York. Las horas locales serán diferentes. Esto requiere configurar correctamente los clientes y los dispositivos; los nombres de zona proceden de la base de datos de zonas horarias de IANA.
Consulta las guías de configuración: Apple Calendar en macOS, iPhone y iPad, Android con DAVx⁵ y Thunderbird. Outlook suele necesitar un complemento de terceros para CalDAV; las limitaciones según la versión se explican en la guía para conectar Outlook.
Cómo evitar errores de zona horaria
Incluye la zona en el título de las reuniones internacionales. «Reunión semanal (09:00 CET)» puede ayudar si el cliente de correo muestra mal la invitación. Pero CET corresponde al horario de invierno; en verano Berlín utiliza CEST. Emplea la abreviatura correcta para la fecha o indica una ciudad que los participantes reconozcan, en lugar de usar CET todo el año.
Vincula la serie a la zona que determina su horario. Si la reunión debe seguir el reloj de la oficina de Berlín, utiliza esa zona y verifica que las repeticiones se calculan en ella. Para los participantes de otros países, la hora local puede variar durante las transiciones. Eso no significa necesariamente que se haya cambiado la reunión: puede haber cambiado la diferencia entre regiones.
Revisa las reuniones importantes durante los cambios de hora. Europa y Norteamérica hacen la transición en fechas distintas, por lo que la diferencia habitual cambia temporalmente. Comprueba la fecha concreta y confirma por escrito la hora de cada parte.
Usa eventos de todo el día cuando lo importante sea la fecha. Este formato sirve para marcar el día de un congreso. Si los asistentes deben llegar a una hora concreta, crea un evento con hora y zona, no solo una fecha. Tampoco asignes una hora arbitraria a un evento que no la necesita.
Revisa las series antiguas y, si hace falta, guarda la hora y la zona correctas. Que una entrada antigua no tenga zona no significa que deba tratarse como una hora flotante válida. Al guardar desde el correo web, ten en cuenta los ajustes del navegador. También conviene revisarlos en el envío programado, cuya hora introducida depende de la zona del dispositivo.Preguntas frecuentes
¿Por qué mi reunión aparece a otra hora en otras zonas?
Normalmente, distintas horas locales representan el mismo instante. El problema aparece cuando los participantes reciben momentos de inicio realmente distintos. Comprueba entonces la zona del evento y la configuración de los clientes. Si faltaba la zona, confirma la hora original, guarda el evento con la zona correcta y verifica el resultado con los participantes.
¿Por qué mi reunión periódica se ha desplazado una hora?
Puede deberse al cambio de hora. Una serie con hora UTC fija la mantiene, pero cambia en el reloj local. Una serie calculada en una zona local mantiene esa hora, aunque puede desplazarse para quienes están en otras regiones. El comportamiento correcto depende de lo acordado; comprueba cómo se calcula y exporta tu serie.
¿Qué zona se utiliza al crear un evento en el correo web?
El correo web obtiene automáticamente la zona del navegador y la envía para los eventos con hora. El servidor guarda el instante UTC y la zona. Comprueba los ajustes del dispositivo antes de crear el evento, especialmente si la reunión debe seguir una zona distinta de la tuya.
¿Se convierten los eventos de todo el día?
No. Se guardan como fechas, no como instantes. Convertir una fecha mediante UTC puede hacer que aparezca en el día anterior o siguiente para usuarios de otras zonas.
¿Qué ocurre con los eventos creados antes de guardar las zonas?
Mantienen su comportamiento anterior, sin asignarles una zona automáticamente. El correo web añade la zona del navegador al guardar un evento con hora: revisa primero la hora y los ajustes del dispositivo. Una actualización por API sin un parámetro de zona explícito deja la entrada antigua sin zona.
¿Funcionan bien las zonas con Apple Calendar y Google Calendar?
Un cliente CalDAV compatible puede convertir correctamente la hora si está bien configurado. Hay una guía para conectar Apple Calendar. En Google Calendar, verifica el método de integración disponible: no se puede prometer conexión con cualquier servidor CalDAV externo. Comprueba también las repeticiones y los cambios de hora.
¿Puedo indicar la zona explícitamente mediante la API?
Sí. La API REST para crear y actualizar eventos admite un parámetro de zona horaria. En MCP, consulta el esquema de la herramienta y envía el campo si lo admite. Omitirlo no garantiza que el sistema pueda reconstruir la zona deseada.
¿Por qué los recordatorios de eventos antiguos llegan a una hora incorrecta?
Si la hora se guardó sin zona, compararla con el instante actual puede dar un resultado incorrecto. Confirma la hora original, guarda el evento con la zona adecuada y prueba el recordatorio. Si el problema continúa, revisa también la configuración de las notificaciones y el funcionamiento del programador de tareas.
