Uma franquia com unidades em vários fusos horários tinha um problema no site que ninguém tinha pensado em corrigir: a seção central de “horário” em cada página de unidade mostrava o mesmo horário, escrito uma vez por alguém na sede e copiado para todas as lojas, independentemente do fuso horário em que cada loja realmente funcionava. Uma unidade no lado oeste do território da franquia, que fechava às 9 da tarde pelo seu próprio relógio, parecia no site fechar três horas antes do que realmente fechava, porque o horário tinha sido escrito com base no horário da sede e nunca ajustado por unidade.
Corrigir isso exigiu associar um fuso horário real a cada unidade, em vez de tratar o “horário” como um único conteúdo compartilhado. Para o endereço de cada unidade da franquia, a empresa resolveu as coordenadas por /v1/forward e passou essas coordenadas para /v1/timezone, que retorna o nome de fuso horário IANA daquele ponto exato. Armazenar o nome, e não um deslocamento fixo, fez com que a exibição do horário continuasse correta automaticamente nas mudanças de horário de verão, sem que ninguém na sede precisasse se lembrar de atualizar nada duas vezes por ano.
Com o fuso horário de cada unidade cadastrado, o site finalmente pôde fazer o que deveria ter feito desde o início: mostrar ao visitante se uma unidade específica estava aberta naquele momento, calculado corretamente pelo relógio da própria unidade, não pelo relógio do visitante nem pelo da sede. Um visitante navegando do outro lado do país e olhando a página de uma loja na costa oposta via um “aberto agora” ou “fechado, abre às 8 da manhã” preciso, refletindo o horário local real daquela loja, que é a única versão dessa informação realmente útil para quem está prestes a dirigir até lá.
A empresa acrescentou a localização do próprio visitante a isso, especificamente no localizador de unidades. /v1/ip resolvia as coordenadas aproximadas do cliente que visitava o site, que alimentavam a mesma classificação por distância usada por outras ferramentas de localização, de modo que um cliente procurando a unidade aberta mais próxima recebia resultados que consideravam tanto a distância quanto se aquela unidade estava realmente aberta no momento da busca, em vez de uma lista ordenada por distância com várias lojas fechadas misturadas às abertas.
Foi uma correção pequena e quase invisível, no sentido de que um visitante do site nunca pensaria em dar crédito ao “tratamento correto de fusos horários” por nada; ele simplesmente perceberia, ou mais provavelmente nem perceberia, que o horário exibido correspondia à realidade. Esse costuma ser o sinal de uma correção que vale a pena fazer: ninguém a elogia, mas todo mundo que teria ficado confuso com a versão antiga simplesmente não fica mais confuso.
A geocodificação foi executada uma vez por unidade, como parte de uma configuração única, um lote pequeno considerando quantas unidades a maioria das franquias opera, bem dentro da cota diária gratuita. As consultas de fuso horário do recurso “aberto agora”, voltado ao visitante, acrescentaram um volume contínuo leve ligado ao tráfego do localizador de unidades, também folgadamente dentro do nível gratuito para uma franquia de porte médio, com crédito pré-pago disponível caso uma campanha de marketing nacional provocasse um pico incomum de buscas por unidades.
A documentação dos dois endpoints está em /docs/forward-geocoding/ e /docs/timezone-lookup/.
Um código postal e uma cidade que não batem em um formulário de pedido parecem um pequeno erro de digitação até virarem uma entrega enviada para uma região totalmente diferente do país.
Uma empresa de logística queria um alerta simples no momento em que um caminhão de entregas entrasse ou saísse do local de um cliente específico, sem construir ou licenciar uma plataforma completa de rastreamento de frota.
Uma ferramenta de colaboração queria que os colegas de equipe vissem, de relance, onde um colega estava e mais ou menos que horas eram para ele, sem que ninguém precisasse digitar isso no perfil.