Программы, вычисляющие смещения часовых поясов, часто неявно предполагают, что текущее правило для пояса действовало всегда, и это предположение отлично работает ровно до тех пор, пока не понадобится правильно интерпретировать метку времени до последнего изменения правила, и тогда оно незаметно выдаёт неверный ответ, который выглядит вполне правдоподобно. Это действительно распространённый источник тонкого искажения данных в системах, которые хранят или обрабатывают исторические метки времени за значительный промежуток времени.
Это важно потому, что правила часовых поясов, даты начала и окончания летнего времени, стандартные смещения и даже принадлежность места к тому или иному поясу не зафиксированы навсегда. Они меняются, когда их меняют правительства, как описано в другой статье, и для метки времени, записанной несколько лет назад, чтобы вычислить соответствующий ей момент в другом поясе или в UTC, нужно правило, которое действительно действовало в эту конкретную дату, а не правило, действующее сегодня.
Именно поэтому база данных часовых поясов IANA хранит полную историю изменений правил для каждого именованного пояса, а не только текущее правило. Программы, правильно построенные на её основе, могут ответить на вопрос «каким было смещение от UTC для этого пояса в эту конкретную историческую дату», а это действительно другой и более сложный вопрос, чем «каково смещение от UTC для этого пояса прямо сейчас», и именно из-за их путаницы исторические данные о времени незаметно становятся неверными.
Это проявляется вполне конкретно и практически. Системе, которая переводит историческую метку времени из журнала из местного времени в UTC для анализа, нужно историческое правило для исходной даты и пояса этого журнала, а не текущее, иначе преобразование вносит ошибку, которая может достигать целого часа в любую сторону в зависимости от конкретного перехода. Системе, вычисляющей чей-то возраст или срок действия договора по датам, между которыми было историческое изменение правила, нужна та же осторожность, хотя влияние там обычно меньше. Даже для того, чтобы показать пользователю старую метку времени в его текущем местном времени, нужно выполнить преобразование по правильному историческому правилу для исходного пояса и даты, а не по текущему.
Практическая рекомендация: всегда выполняйте преобразования часовых поясов с помощью системы, которая учитывает исторические изменения правил для конкретного пояса и даты, а не знает только текущее правило, и будьте особенно внимательны к любому процессу, который пакетно преобразует исторические данные за период, в который могло попасть изменение правила. Наше определение часового пояса можно запросить для конкретного момента времени, и оно применит правила, действительно действовавшие в эту дату, а это именно то поведение, которое нужно для правильной обработки исторических данных, вместо того чтобы по умолчанию применять сегодняшнее правило к каждому расчёту, какая бы дата на самом деле ни обрабатывалась.