Fique a uma curta distância da Linha Internacional de Data e é perfeitamente possível que o seu vizinho do outro lado dessa linha esteja em uma data de calendário diferente da sua, mesmo que vocês dois estejam vendo mais ou menos a mesma hora local no relógio e estejam fisicamente próximos um do outro. Esse é um dos fatos realmente mais desorientadores sobre como a contagem do tempo no mundo é organizada, e ele tem consequências reais e práticas para qualquer lógica sensível a datas que opere perto dela.
A linha de data existe porque os fusos horários se acumulam ao redor do globo até se encontrarem em algum lugar e, por uma convenção antiga, esse ponto de encontro segue aproximadamente o meridiano de 180 graus no Pacífico, traçado de propósito por mar aberto e ao redor de terras habitadas tanto quanto possível, justamente para reduzir o número de lugares que ficam bem em cima do salto. Atravessá-la em um sentido faz a sua data voltar um dia. Atravessá-la no outro faz a data avançar um dia. Isso é separado e adicional à diferença normal de fuso horário que você esperaria ao cruzar qualquer outro limite de fuso.
Para a maioria das aplicações, isso simplesmente nunca aparece, já que a linha de data passa principalmente pelo oceano e o número de pessoas e empresas que operam bem na borda dela é pequeno. Isso se torna uma preocupação real especificamente para aplicações que operam nos países e territórios insulares do Pacífico perto da linha, onde um sistema de agendamento, uma plataforma de reservas ou qualquer coisa que calcule "que dia é agora neste local" precisa acertar o traçado exato da linha de data, e não só o deslocamento geral do fuso horário, ou vai calcular uma data de calendário aparentemente plausível, mas errada, para locais muito próximos dela.
É exatamente por isso que depender de uma consulta de fuso horário adequada, vinculada à zona IANA real de um local específico, importa mais aqui do que em quase qualquer outro lugar. Um cálculo ingênuo baseado apenas na longitude e em uma fórmula simples de deslocamento vai errar a linha de data, já que o traçado real da linha se desvia de propósito de uma linha reta de longitude em vários pontos, justamente para manter alguns países e territórios insulares em uma única data consistente, em vez de dividi-los de forma estranha entre os dois lados da linha.
Se a sua aplicação opera em qualquer lugar perto do Pacífico e calcula datas, não apenas horários, com base na localização, use uma consulta de fuso horário adequada, vinculada à zona real daquela coordenada, em vez de derivar a data diretamente da longitude, e teste explicitamente com locais conhecidos por ficarem perto da linha de data, em vez de supor que o seu tratamento geral de fuso horário cobre automaticamente esse caso extremo específico da forma correta.
Um endereço no centro de uma cidade bem mapeada quase não diz nada sobre como o seu sistema lida com uma estrada rural, uma fronteira disputada ou uma consulta perto dos polos. Teste os casos difíceis de propósito.
Nem todo conjunto de dados com informações de localização de aparência pública pode ser usado legalmente dentro de um produto pago. Os termos de licenciamento, e não a disponibilidade técnica, costumam definir o limite real.
Quando uma consulta realmente não pode ser resolvida de forma confiável, não retornar nada é uma resposta melhor do que retornar um palpite disfarçado de fato. Veja o raciocínio por trás dessa escolha.