"Únete el jueves a las 2 PM, hora del Este" es preciso exactamente para los asistentes que ya piensan en hora del Este y un juego de adivinanzas para todos los demás. Una empresa de software B2B que organiza webinars periódicos para una audiencia internacional descubrió que una parte notable de las ausencias y las incorporaciones tardías se debía a que los asistentes simplemente calculaban mal la diferencia horaria, o no la calculaban en absoluto y suponían que la invitación se refería a las 2 PM de su propia hora local.
El formulario de registro de la empresa ya recogía una dirección de correo electrónico y, para fines de programación, una ubicación aproximada, introducida directamente o deducida de la dirección IP de la persona en el momento de registrarse, resuelta mediante /v1/ip en coordenadas junto con el país y la ciudad. Esas coordenadas se enviaban a /v1/timezone, que devolvía el nombre de la zona horaria IANA de la ubicación de la persona registrada, lo que daba a la empresa una forma fiable de calcular la hora local correcta del webinar para ese asistente concreto, en lugar de depender de que el asistente hiciera la conversión por su cuenta.
A partir de entonces, cada correo de confirmación mostraba la hora del webinar dos veces: una en la zona horaria del presentador, por coherencia, y otra calculada específicamente para la zona horaria obtenida de ese asistente, escrita en lenguaje claro y no como un desfase con el que el lector tuviera que hacer más cálculos. La misma doble indicación se trasladaba a la invitación de calendario adjunta a la confirmación, de modo que un asistente que añadía el evento a su propio calendario lo veía aparecer automáticamente a la hora local correcta, sin tener que fiarse de una conversión manual.
Como los webinars solían programarse con semanas de antelación, a veces cruzando un cambio de horario de verano en una región pero no en otra, la empresa se apoyó en la capacidad de la consulta de zona horaria para calcular el desfase correcto para la fecha futura concreta del webinar, en lugar del desfase vigente el día en que se enviaba la invitación. Guardar el nombre IANA en lugar de un desfase fijo hacía que esto siguiera siendo correcto sin que nadie en la empresa tuviera que vigilar qué regiones estaban a punto de cambiar la hora y ajustar las invitaciones a mano.
El resultado medible fue un descenso importante del número de correos a soporte y ventas pidiendo confirmar la hora local real de una próxima sesión, un coste pequeño pero recurrente en tiempo del personal que hasta entonces se consideraba una parte inevitable de organizar webinars internacionales. La asistencia también mejoró de forma moderada, aunque la empresa tuvo cuidado de señalar que esa mejora probablemente se debía a una combinación de factores, siendo una indicación más clara de la zona horaria uno de varios y no la única explicación.
El volumen era bajo y predecible, una consulta por persona registrada en el momento del registro, una carga que nunca se acercó a la cuota diaria gratuita, ni siquiera para una empresa que organiza webinars con frecuencia, ya que el volumen de registros de un evento concreto rara vez alcanza una escala en la que el coste de las solicitudes se convierta en un factor relevante.
Acertar con la hora de una reunión para cada asistente, de forma individual, en lugar de pedir a cada persona que haga su propia conversión, elimina una fuente de fricción pequeña pero real de algo tan sencillo como presentarse a una llamada programada. La documentación de ambos endpoints está en /docs/ipv4-lookup/ y /docs/timezone-lookup/.