Uma consulta de fuso horário raramente ganha um item próprio nas notas de arquitetura de um projeto. Normalmente ela vem junto dentro de uma conta da Google Maps Platform criada para geocodificação ou exibição de mapas, chamada de onde quer que um timestamp precise ser convertido para o horário local de uma coordenada. Esse agrupamento é justamente o que torna um pouco complicado migrá-la sozinha: a conta, a cobrança e a chave são todas compartilhadas com recursos que talvez você não esteja migrando ao mesmo tempo.
A API de fuso horário do Google recebe uma localização e um timestamp e retorna um timeZoneId, um timeZoneName e valores de deslocamento em segundos, tanto para o horário padrão quanto para qualquer ajuste de horário de verão. É uma resposta pequena e bem definida, o que a torna uma primeira candidata razoável a ser separada de uma conta maior do Google antes de encarar a geocodificação ou algo mais complexo.
O My Geocode oferece a consulta de fuso horário como um endpoint independente e totalmente funcional, e não como uma camada que imita o formato específico do Google, já que esta é uma das consultas em que uma resposta real e funcional pode ser descrita diretamente. Uma requisição para uma coordenada retorna o identificador de fuso horário e as informações de deslocamento necessárias para converter um timestamp UTC para o horário local. Os detalhes estão em /docs/timezone-lookup/.
Como este é um endpoint independente, e não um host compatível equivalente, sair da API de fuso horário do Google significa ajustar os nomes de campos específicos que o seu código lê, o que normalmente é uma mudança pequena e contida, já que os dados de fuso horário são naturalmente enxutos: um identificador, um deslocamento, talvez uma flag de horário de verão. Isso dá bem menos trabalho do que migrar uma integração completa de geocodificação, com o parsing dos componentes de endereço.
Etapas práticas para esta migração específica:
Isole todos os pontos do código que chamam hoje o endpoint de fuso horário do Google, já que ele costuma ser chamado a partir de apenas uma ou duas funções utilitárias, mesmo em um código maior
Teste com coordenadas em regiões com regras de fuso horário incomuns, como lugares que adotam deslocamentos de meia hora ou áreas sem horário de verão, já que é nesses casos extremos que conversões ingênuas costumam falhar
Atualize a autenticação para uma chave enviada como X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta, o que se encaixar de forma mais natural no seu código de requisição atual
Os preços aqui são os mesmos de todos os outros endpoints: 2.500 requisições gratuitas por dia sem chave, mais 2.500 gratuitas por chave por dia, contadas por rede, e depois crédito pré-pago a € 0,0001 por requisição ou uma chave Unlimited a € 50 por mês. Se o uso da Google Maps Platform na sua conta era principalmente de chamadas de fuso horário com geocodificação ocasional, migrar só a parte de fuso horário pode reduzir de forma significativa o que continua ligado à conta original, e o restante da migração pode seguir no seu próprio ritmo.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.
Desligar a chave de API de um provedor antigo cedo demais ou tarde demais traz riscos nos dois casos. Veja como aposentar credenciais corretamente quando uma migração estiver concluída.