"UTC menos cinco" não é um fuso horário, é uma diferença, e as diferenças mudam duas vezes por ano na maioria dos países que adotam horário de verão. É exatamente por isso que uma equipe remota de doze pessoas marcava reuniões que ficavam corretas durante meses e, de repente, deixavam de ficar, bem perto de uma mudança de relógio que ninguém do lado do agendamento tinha pensado em verificar.
A equipe mantinha uma planilha simples que associava a cidade de cada colega a uma diferença fixa em relação à sede da empresa, atualizada à mão sempre que alguém lembrava que o horário de verão estava chegando. A planilha ficava errada durante cerca de seis meses do ano, de forma rotativa, dependendo de quais países tinham mudado os relógios e quais não, já que nem todos os países adotam o horário de verão no mesmo calendário, e alguns nem o adotam.
A solução foi substituir a planilha por uma consulta que refletisse as regras reais de fuso horário, em vez de um retrato que alguém tinha digitado uma vez. Para a cidade de cada colega, a equipe obteve uma coordenada e a enviou para /v1/timezone, que retorna o nome do fuso horário IANA daquele ponto, um nome como "America/Sao_Paulo" ou "Asia/Kolkata", e não uma diferença pura. Esse nome traz consigo as regras reais de horário de verão daquela região específica, então uma ferramenta de agendamento que armazena o nome IANA e calcula a diferença atual a partir dele, em vez de armazenar a diferença diretamente, continua correta automaticamente quando os relógios mudam, já que as regras ficam no banco de dados de fusos horários, e não em um valor que alguém precisa lembrar de atualizar.
A equipe integrou isso diretamente à sua ferramenta de agendamento de reuniões, de modo que propor um horário de reunião mostrava corretamente o horário local de cada participante, calculado na hora em que a reunião estava sendo marcada, e não puxado de uma tabela estática. Para uma reunião proposta com semanas de antecedência, a capacidade do endpoint de calcular a diferença para um momento futuro específico também importava, já que uma reunião marcada antes da mudança de relógio de uma região e realizada depois dela precisava da diferença correta pós-mudança, e não da diferença em vigor no dia em que foi marcada.
A mudança visível foi ter menos erros de agendamento e menos mensagens de desculpas por uma reunião que tinha caído em um horário absurdo para alguém. A mudança menos visível foi que ninguém na equipe precisava mais lembrar os calendários de horário de verão de quatro países, algo que antes era, de fato, uma responsabilidade informal e não remunerada de alguém.
Esse tipo de solução funciona tão bem em escala pequena quanto em escala grande. Uma equipe de doze pessoas e uma empresa de mil pessoas têm o mesmo problema de fundo, apenas em volumes diferentes, e a consulta em si não fica mais complexa em nenhum dos casos, só muda a frequência com que é chamada. Para uma equipe pequena, o uso ficou folgadamente dentro da cota diária gratuita incluída em uma chave, já que obter os fusos horários de uma dúzia de pessoas algumas vezes é uma carga mínima perto das 2.500 requisições gratuitas disponíveis por dia.
Bugs de fuso horário costumam ser invisíveis até causarem um problema real, e aí o estrago é uma reunião perdida ou um cliente confuso. Corrigir a fonte de dados de uma vez elimina toda essa categoria de erro daqui para a frente. A documentação do endpoint está em /docs/timezone-lookup/.