A funcionalidade de fuso horário do Bing geralmente é acessada pela Locations API com uma flag de fuso horário ou por uma chamada dedicada de fuso horário, dependendo de como a integração foi construída originalmente. De qualquer forma, ela costuma ficar na mesma conta do Bing Maps Dev Center que a geocodificação, o que significa que uma migração completa da conta normalmente afetaria as duas ao mesmo tempo, mesmo quando só a parte de fuso horário está realmente em questão.
Os dados de fuso horário são uma resposta pequena e bem delimitada: um identificador, um deslocamento em relação ao UTC e, geralmente, uma indicação sobre a observância do horário de verão para a coordenada e a data informadas. Essa compactação é uma vantagem real ao planejar uma migração, porque há relativamente pouca estrutura de resposta a verificar em casos de teste reais antes de dar a mudança por concluída.
A consulta de fuso horário do My Geocode funciona como um endpoint independente e totalmente funcional, documentado em /docs/timezone-lookup/, totalmente separado dos hosts compatíveis de geocodificação. Ela retorna diretamente as informações de fuso horário de uma coordenada, o que significa que esta migração não exige decidir nada antes sobre o resto de uma integração com o Bing Maps. As equipes podem mover as chamadas de fuso horário agora e levar mais tempo avaliando se também vão migrar a geocodificação.
Etapas que vale seguir especificamente nesta migração:
Identifique todas as funções que chamam hoje a funcionalidade de fuso horário do Bing, lembrando que ela pode estar embutida em uma chamada mais ampla da Locations API, e não em um endpoint separado no código existente
Extraia essa lógica para uma função própria com nome claro, se ela ainda não estiver separada, o que torna a troca de provedor uma única mudança localizada
Teste o novo endpoint com coordenadas que tenham comportamento de fuso horário incomum conhecido (regiões com deslocamentos que não são horas inteiras, lugares sem horário de verão) antes de considerar a migração verificada
A autenticação usa uma chave, enviada como X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta, o que melhor corresponder à forma como o resto da sua aplicação já envia credenciais para outros serviços.
Os preços são os mesmos para tudo: 2.500 requisições gratuitas por dia sem necessidade de 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, sem um preço separado para consultas de fuso horário em relação a qualquer outro endpoint. Considerando como a maioria das aplicações faz poucas chamadas de fuso horário em comparação com o volume de geocodificação, é comum que esta parte específica fique tranquilamente dentro da cota diária gratuita mesmo após uma migração completa, o que vale a pena conferir com os seus próprios números antes de presumir que ela precisa de um plano pago.
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.