Duas vezes por ano, nos fusos que adotam horário de verão, acontece algo estranho com o relógio que a maioria dos softwares nunca leva em conta. Quando os relógios são adiantados, uma hora do horário local simplesmente não existe, então um timestamp como "2:30 AM" naquela data nunca ocorreu de fato. Quando os relógios são atrasados, uma hora acontece duas vezes, então "1:30 AM" ocorreu uma vez antes da mudança e outra depois, e um timestamp local puro, sem nenhuma outra informação, não consegue dizer a qual delas se refere.
Esse não é um caso extremo raro que só importa em usos exóticos. É um evento de calendário rotineiro, que se repete todo ano em todos os fusos que usam horário de verão, e ele quebra silenciosamente qualquer código que trate o horário local como sempre bem definido. Um sistema de agendamento que armazena "reservar para 1:45 AM" sem armazenar também a diferença de UTC no momento da reserva não consegue saber, meses depois, qual das duas 1:45 AM era a pretendida se a reserva cair na noite da transição.
A prática mais segura é armazenar timestamps em UTC em todo o sistema internamente e converter para o horário local apenas na exibição. O UTC não tem horário de verão nem ambiguidade, então, depois que um momento é registrado assim, ele continua correto independentemente do que aconteça depois com as regras do relógio local. Converta para o fuso horário local do usuário apenas no momento de mostrar a ele, usando as regras atuais daquele fuso para aquele momento específico, e é exatamente por isso que vale a pena usar uma consulta de fuso horário que aceite um instante específico, e não apenas um local, em vez de armazenar uma diferença em cache uma vez e reutilizá-la.
Os casos extremos que vale a pena testar explicitamente, se você constrói qualquer coisa que agende ou registre eventos, incluem: uma reserva feita para a hora inexistente durante uma transição em que o relógio é adiantado, um timestamp durante a hora repetida de uma transição em que o relógio é atrasado e um evento agendado cuja data atravessa uma transição entre o momento em que foi criado e o momento em que acontece. Nenhum deles é hipotético. Eles acontecem em um calendário fixo e previsível todo ano, e testá-los uma vez durante o desenvolvimento é muito mais barato do que depurar um chamado de suporte sobre uma reunião que parece ter se deslocado uma hora.
Se o seu sistema precisa da diferença correta para um momento específico, e não apenas do nome do fuso, solicite-a diretamente em vez de derivá-la de um valor em cache. A consulta de fuso horário da My Geocode aceita um momento específico e aplica as regras de horário de verão daquela data exata, então a diferença retornada está correta mesmo bem no limite de uma transição.