Dos veces al año, en las zonas que aplican el horario de verano, le pasa algo extraño al reloj que la mayoría del software nunca tiene en cuenta. Cuando los relojes se adelantan, una hora de la hora local simplemente no existe, así que una marca de tiempo como "2:30 a. m." en esa fecha nunca llegó a ocurrir. Cuando los relojes se atrasan, una hora ocurre dos veces, así que "1:30 a. m." ocurrió una vez antes del cambio y otra después, y una marca de tiempo local sin más información no puede decirte a cuál se refiere.
No es un caso límite raro que solo importe en usos exóticos. Es un acontecimiento rutinario del calendario que se repite cada año en todas las zonas que usan el horario de verano, y rompe en silencio cualquier código que trate la hora local como algo siempre bien definido. Un sistema de reservas que almacena "reservar esto para las 1:45 a. m." sin almacenar también el desfase UTC en el momento de la reserva no puede saber, meses después, a cuál de las dos 1:45 a. m. se refería si la reserva cae en la noche del cambio.
La práctica más segura es almacenar internamente todas las marcas de tiempo en UTC y convertirlas a hora local solo para mostrarlas. UTC no tiene horario de verano ni ambigüedad, así que una vez que un momento se captura así, sigue siendo correcto pase lo que pase después con las reglas del reloj local. Convierte a la zona horaria local del usuario solo en el momento de mostrársela, usando las reglas vigentes para esa zona en ese momento concreto, y precisamente por eso conviene usar una consulta de zona horaria que acepte un momento concreto, y no solo una ubicación, en lugar de guardar en caché un desfase una vez y reutilizarlo.
Si creas algo que programa o registra eventos, estos son casos límite que conviene probar explícitamente: una reserva hecha para la hora inexistente durante el adelanto de primavera, una marca de tiempo durante la hora repetida del atraso de otoño y un evento programado cuya fecha cruza un cambio de horario entre el momento en que se creó y el momento en que ocurre. Ninguno de ellos es hipotético. Ocurren cada año según un calendario fijo y predecible, y probarlos una vez durante el desarrollo es mucho más barato que depurar un ticket de soporte sobre una reunión que parece haberse movido una hora.
Si tu sistema necesita el desfase correcto para un momento concreto y no solo el nombre de la zona, solicítalo directamente en lugar de deducirlo de un valor en caché. La consulta de zona horaria de My Geocode acepta un momento concreto y aplica las reglas de horario de verano de esa fecha exacta, así que el desfase devuelto es correcto incluso justo en el límite de un cambio.