Guias

Crie um seletor de fuso horário que usa o fuso do visitante como padrão

Rolar por uma lista de nomes de fusos horários para encontrar o seu é um pequeno incômodo que um padrão sensato elimina para quase todo mundo.

Detectando o fuso

O endpoint /v1/ip retorna diretamente um campo timezone, então uma única chamada entrega a localização e o identificador de fuso horário juntos, sem uma chamada separada ao endpoint de fuso horário.

GET /v1/ip?ip=203.0.113.88
{
  "status": "ok",
  "ip": "203.0.113.88",
  "version": 4,
  "found": true,
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "postcode": "2000",
  "lat": -33.8688,
  "lon": 151.2093,
  "timezone": "Australia/Sydney",
  "asn": 7890,
  "org": "Example Networks"
}

Pré-selecionando o seletor

Defina o valor timezone dessa resposta como a opção selecionada no seu formulário de configurações quando ele for renderizado pela primeira vez, no servidor, antes de a página chegar ao visitante. Isso funciona da mesma forma quer o seletor seja uma lista suspensa de identificadores de fuso padrão ou uma lista pesquisável, já que o valor que você está pré-selecionando é apenas uma string de identificador padrão, como a do exemplo.

Um segundo exemplo: várias pessoas em uma mesma reserva

Um formulário de reserva de viagem ou de evento que coleta dados de mais de um viajante se beneficia de detectar o fuso uma vez para a pessoa que está preenchendo o formulário e depois aplicá-lo como padrão compartilhado para cada viajante, em vez de consultá-lo de novo para cada um. Cada campo de viajante continua editável individualmente, já que uma reserva em grupo muitas vezes inclui pessoas que participam de um fuso diferente do de quem está preenchendo o formulário.

Permitindo que o visitante substitua o valor

Um seletor de fuso horário existe justamente porque a detecção baseada em IP nem sempre acerta, especialmente para um visitante usando VPN ou em viagem. Deixe sempre o campo editável e salve o que o visitante escolher explicitamente no lugar do padrão detectado, sem detectar de novo e sobrescrever a escolha dele em uma visita posterior.

Um erro comum a evitar

Não presuma que um país grande corresponde a um único fuso horário só porque as suas consultas de exemplo por acaso mostram um identificador limpo. Países que abrangem vários fusos vão retornar o fuso específico que corresponde à localização real do visitante, que é exatamente o detalhe que torna a detecção baseada em IP mais útil do que um palpite no nível do país, mas somente se o seu formulário confiar no identificador específico retornado, em vez de substituí-lo por um único fuso padrão para o país inteiro.

Detecte uma vez, não a cada visita

Execute a detecção uma vez, na primeira vez que um visitante configurar a conta ou as preferências, e armazene o resultado. Executá-la de novo a cada login desperdiçaria requisições sem agregar valor, já que o fuso escolhido pelo visitante, uma vez definido deliberadamente, deve permanecer a menos que ele mesmo o altere.

Se você já tem coordenadas específicas em vez de um endereço IP, como um endereço de entrega digitado pelo visitante, o /v1/timezone resolve o fuso diretamente a partir da latitude e da longitude e também pode aceitar um timestamp específico, o que é útil quando você precisa saber o fuso como ele se aplicava em um determinado momento, e não agora.

Quanto custa

Uma única consulta por nova conta ou configuração de preferências é uma requisição. Mesmo um serviço que cadastra um fluxo constante de novos usuários por dia fica bem dentro das 2.500 requisições gratuitas por dia incluídas em toda chave, ou disponíveis a partir de um único endereço sem chave, usando apenas este recurso.

Detectar um padrão sensato e depois sair do caminho é o equilíbrio certo para um seletor de fuso horário. Todos os detalhes dos campos estão na documentação de consulta de IPv4 e na documentação de consulta de fuso horário.