Softwares que calculam deslocamentos de fuso horário muitas vezes supõem implicitamente que a regra atual de um fuso sempre se aplicou, e essa suposição funciona bem até o momento em que você precisa interpretar corretamente um timestamp anterior à mudança de regra mais recente, quando ela passa a produzir silenciosamente uma resposta errada que parece totalmente plausível. Esta é uma fonte realmente comum de corrupção sutil de dados em sistemas que armazenam ou processam timestamps históricos ao longo de um período de tempo considerável.
Isso importa porque as regras de fuso horário, as datas de início e fim do horário de verão, os deslocamentos padrão e até o fuso ao qual um local pertence não são fixos para sempre. Elas mudam quando os governos as mudam, como explicado em outros textos, e um timestamp registrado anos atrás precisa da regra que estava de fato em vigor naquela data específica, e não da regra em vigor hoje, para calcular o momento correspondente correto em outro fuso ou em UTC.
É exatamente por isso que o banco de dados de fusos horários IANA armazena o histórico completo das mudanças de regra de cada fuso nomeado, e não apenas a regra atual. Um software construído corretamente sobre ele consegue responder "qual era o deslocamento UTC deste fuso nesta data histórica específica", que é uma pergunta realmente diferente e mais complexa do que "qual é o deslocamento UTC deste fuso agora", e confundir as duas é exatamente como dados históricos de timestamp vão ficando errados sem que ninguém perceba.
Isso aparece de formas concretas e práticas. Um sistema que converte um timestamp histórico de log do horário local para UTC para análise precisa da regra histórica da data e do fuso originais desse log, e não da atual, ou a conversão introduz um erro que pode chegar a uma hora inteira em qualquer direção, dependendo da transição específica envolvida. Um sistema que calcula a idade de alguém ou a duração de um contrato entre datas que abrangem uma mudança histórica de regra precisa do mesmo cuidado, embora o impacto nesse caso costume ser menor. Até exibir um timestamp antigo para um usuário no horário local atual dele exige converter pela regra histórica correta do fuso e da data originais, e não pela atual.
A orientação prática é sempre calcular conversões de fuso horário com um sistema que conheça as mudanças históricas de regra do fuso e da data em questão, e não com um que só conheça a regra atual, e ter cuidado especial com qualquer processo que converta em lote dados históricos ao longo de um período que possa incluir uma mudança de regra. A nossa consulta de fuso horário pode ser feita para um momento específico no tempo, aplicando as regras que estavam de fato em vigor naquela data, que é exatamente o comportamento necessário para tratar dados históricos corretamente, em vez de usar por padrão a regra de hoje em todos os cálculos, qualquer que seja a data realmente processada.