O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
Por que bugs de fuso horário geralmente são um problema de teste, e não de dados
Um bug de fuso horário quase nunca aparece em uma terça-feira comum. Ele aparece na semana específica em que acontece uma transição do horário de verão, ou em uma região cujo governo acabou de mudar as regras de diferença horária com pouco aviso, ou no limite exato entre dois fusos, onde um caso extremo no mapeamento de coordenadas para fuso escolhe o lado errado. No resto do ano, o código que trata mal os fusos horários roda sem nenhum problema visível, e é exatamente isso que torna esses bugs tão persistentes: o modo de falha é raro por natureza, então raramente é detectado até realmente acontecer em produção.
Achamos que a maioria desses bugs é atribuída aos dados quando, na verdade, é uma lacuna de testes. O banco de dados de fusos horários da IANA, que está por trás da maior parte do tratamento sério de fusos horários, incluindo o nosso, acompanha essas transições e mudanças de regras conforme elas acontecem. Os dados estarem disponíveis não é o mesmo que uma aplicação exercitar corretamente os caminhos de código que só rodam durante uma semana de transição ou que só se aplicam ao punhado de regiões com regras incomuns. Se um conjunto de testes nunca simula um limite de horário de verão, ou nunca faz uma consulta para uma região com uma diferença horária fora do padrão, de meia hora ou de 45 minutos, os dados subjacentes estarem corretos não vão salvar uma aplicação de um bug que só o seu próprio caminho de código não testado poderia evitar.
Este é um caso em que a correção é chata e específica, e não empolgante: teste explicitamente nas datas do calendário em que as transições ocorrem, e não apenas em uma data arbitrária escolhida por conveniência. Teste deliberadamente um punhado de regiões de casos extremos com diferenças horárias incomuns, e não apenas os fusos horários comuns, de números redondos, em que a maior parte do desenvolvimento por acaso acontece. Nada disso exige novos dados. Exige decidir que a semana rara merece ser testada com o mesmo cuidado que a semana comum, já que a semana rara é exatamente quando o bug vai aparecer para um usuário real.
Há uma armadilha relacionada que vale a pena nomear: armazenar em cache a diferença horária de um local uma vez e reutilizar esse valor em cache indefinidamente. Uma diferença que estava correta em julho pode estar errada em dezembro, depois que o horário de verão a altera, e um cache que não leva isso em conta vai servir com confiança uma resposta desatualizada sem nenhuma indicação de que algo deu errado. Isso também não é um problema de qualidade de dados. É uma decisão de arquitetura que presumiu que um fato permaneceria constante, quando a própria natureza desses dados é que, periodicamente, ele não permanece.
Descrevemos o nosso endpoint de fuso horário como uma das partes do produto que está totalmente funcional, porque os dados de referência subjacentes são mantidos ativamente e a lógica de consulta foi construída para levar essas transições em conta diretamente, em vez de presumir uma diferença horária estática. O ponto maior vale além do nosso próprio produto: um bug de fuso horário que chega a um cliente raramente é prova de que os dados de origem estavam errados. Muito mais frequentemente, é prova de que ninguém escreveu um teste para a única semana do ano, ou a única região, em que as regras realmente mudam.