"Participe na quinta-feira às 2 PM, horário do Leste" é preciso exatamente para os participantes que já pensam no horário do Leste dos EUA e um jogo de adivinhação para todos os outros. Uma empresa de software B2B que realiza webinars regulares para um público internacional descobriu que uma parcela perceptível das ausências e das entradas atrasadas vinha de participantes que simplesmente erravam a conta do fuso horário, ou nem faziam a conta e presumiam que o convite se referia às 2 PM do seu próprio horário local.
O formulário de inscrição da empresa já coletava um endereço de e-mail e, para fins de agendamento, uma localização aproximada, informada diretamente ou deduzida do endereço IP da pessoa no momento da inscrição, resolvido por meio de /v1/ip em coordenadas, junto com país e cidade. Essas coordenadas alimentavam /v1/timezone, que retornava o nome do fuso horário IANA da localização da pessoa inscrita, dando à empresa uma forma confiável de calcular o horário local correto do webinar para aquele participante específico, em vez de depender de o próprio participante fazer a conversão.
A partir daí, cada e-mail de confirmação mostrava o horário do webinar duas vezes: uma no fuso horário do apresentador, para manter a consistência, e outra calculada especificamente para o fuso horário resolvido daquele participante, escrita em linguagem simples, e não como um deslocamento que exigiria mais contas do leitor. A mesma exibição dupla se estendia ao convite de calendário anexado à confirmação, de modo que o participante que adicionava o evento ao próprio calendário o via cair automaticamente na hora local correta, sem precisar confiar em uma conversão manual.
Como os webinars costumavam ser agendados com semanas de antecedência, às vezes atravessando uma mudança de horário de verão em uma região, mas não em outra, a empresa contava com a capacidade da consulta de fuso horário de calcular o deslocamento correto para a data futura específica do webinar, e não o deslocamento em vigor no dia em que o convite foi enviado. Armazenar o nome IANA em vez de um deslocamento fixo fazia com que isso continuasse correto sem que ninguém na empresa precisasse acompanhar quais regiões estavam prestes a mudar os relógios e ajustar os convites manualmente.
O resultado mensurável foi uma queda significativa no número de e-mails ao suporte e às vendas pedindo confirmação do horário local real de uma sessão futura, um custo pequeno, mas recorrente, em tempo da equipe, que antes era tratado como parte inevitável de realizar webinars internacionais. A participação também melhorou um pouco, embora a empresa tenha feito questão de observar que a melhora provavelmente veio de uma combinação de fatores, sendo a exibição mais clara do fuso horário um dos vários contribuintes, e não uma explicação única.
O volume era baixo e previsível, uma consulta por pessoa inscrita no momento da inscrição, uma carga que nunca chegou perto da cota diária gratuita, mesmo para uma empresa que realiza webinars com frequência, já que o volume de inscrições de um único evento raramente atinge uma escala em que o custo por requisição se torne uma consideração relevante.
Acertar o horário de uma reunião para cada participante, individualmente, em vez de pedir que cada pessoa faça a própria conversão, elimina uma fonte pequena, mas real, de atrito em algo tão simples quanto comparecer a uma chamada agendada. A documentação dos dois endpoints está em /docs/ipv4-lookup/ e /docs/timezone-lookup/.