"UTC menos cinco" no es una zona horaria, es un desfase, y los desfases cambian dos veces al año en la mayoría de los países que aplican el horario de verano, que es exactamente la razón por la que un equipo remoto de doce personas programaba reuniones que cuadraban durante meses y de repente dejaban de hacerlo, justo alrededor de un cambio de hora que nadie del lado de la planificación había pensado en comprobar.
El equipo mantenía una hoja de cálculo sencilla que asociaba la ciudad de cada compañero con un desfase fijo respecto a la sede de la empresa, actualizada a mano cada vez que alguien se acordaba de que se acercaba el horario de verano. La hoja de cálculo era incorrecta durante aproximadamente seis meses al año, de forma rotativa, según qué países habían cambiado sus relojes y cuáles no, ya que no todos los países aplican el horario de verano en las mismas fechas, y algunos no lo aplican en absoluto.
La solución fue sustituir la hoja de cálculo por una consulta que reflejara las reglas reales de zona horaria en lugar de una instantánea que alguien había escrito una vez. Para la ciudad de cada compañero, el equipo obtenía una coordenada y la enviaba a /v1/timezone, que devuelve el nombre de zona horaria IANA de ese punto, un nombre como "America/Sao_Paulo" o "Asia/Kolkata" en lugar de un simple desfase. Ese nombre lleva consigo las reglas reales de horario de verano de esa región concreta, así que una herramienta de planificación que almacena el nombre IANA y calcula a partir de él el desfase actual, en lugar de almacenar directamente el desfase, se mantiene correcta automáticamente cuando cambian los relojes, ya que las reglas viven en la base de datos de zonas horarias y no en un valor que alguien tiene que acordarse de actualizar.
El equipo integró esto directamente en su herramienta de planificación de reuniones, de modo que al proponer una hora se mostraba correctamente la hora local de cada asistente, calculada en el momento de programar la reunión en lugar de sacarla de una tabla estática. Para una reunión propuesta con semanas de antelación, también importaba que el endpoint pudiera calcular el desfase para un momento futuro concreto, ya que una reunión programada antes del cambio de hora de una región y celebrada después necesitaba el desfase correcto posterior al cambio, no el que estaba vigente el día en que se programó.
El cambio visible fue que hubo menos errores de planificación y menos mensajes de disculpa por una reunión que había caído a una hora poco razonable para alguien. El cambio menos visible fue que nadie del equipo tuvo que volver a recordar los calendarios de horario de verano de cuatro países, lo que antes había sido de verdad una responsabilidad informal y no remunerada de alguien.
Este tipo de solución se adapta a escala pequeña con la misma facilidad que a escala grande. Un equipo de doce personas y una empresa de mil tienen el mismo problema de fondo, solo que con volúmenes distintos, y la consulta en sí no cambia de complejidad en ningún caso, solo la frecuencia con la que se llama. Para un equipo pequeño, el uso cabía de sobra en la cuota diaria gratuita incluida con una clave, ya que obtener las zonas horarias de una docena de personas unas cuantas veces es una carga mínima frente a las 2.500 solicitudes gratuitas disponibles cada día.
Los errores de zona horaria suelen ser invisibles hasta que causan un problema real, y para entonces el daño es una reunión perdida o un cliente confundido. Corregir una vez la fuente de datos subyacente elimina toda esa categoría de errores en adelante. La documentación del endpoint está en /docs/timezone-lookup/.