Часовой пояс является политическим решением прежде, чем географическим. Граница между двумя поясами, решение о переходе на летнее время и точная дата, когда часы переводятся вперёд или назад, устанавливаются национальными или местными властями, и любое из этих решений может измениться. Поэтому данные о часовых поясах не могут быть статической таблицей смещений, застывшей в какой-то момент в прошлом. Они должны быть сопровождаемой записью истории, текущих правил и известных будущих изменений.
База данных часовых поясов IANA является эталоном, на который опирается большинство программ, именно по этой причине. Её сопровождающие отслеживают изменения официального времени по мере того, как правительства о них объявляют, будь то изменение политики перехода на летнее время, изменение смещения от UTC, которое соблюдает регион, или корректировка границ между поясами внутри страны. Каждая именованная зона, например Europe/Amsterdam или America/Chicago, содержит не только текущее правило, но и полную историю прошлых правил, потому что программам часто нужно вычислить правильное смещение для даты в прошлом, а не только для сегодняшнего дня.
Эта история важнее, чем может показаться. Для отметки времени нескольколетней давности нужно смещение, которое фактически действовало на ту дату и может отличаться от действующего сегодня, если правила за это время изменились. Определение часового пояса, которое знает только текущее правило, будет незаметно выдавать неверные результаты для прошлых или будущих дат, поэтому, когда дата имеет значение, стоит запрашивать у API часовых поясов зону на конкретный момент, а не только название зоны.
По той же причине определение часового пояса должно возвращать фактическое название зоны, а не только числовое смещение. За Europe/Amsterdam стоит вся история и вся логика перехода на летнее время. +01:00 верно лишь для части года и ничего не говорит о том, когда оно меняется. Программа, которая хранит для места только смещение, перестанет быть корректной при следующем переходе на летнее или зимнее время, тогда как программа, которая хранит название зоны, остаётся корректной бессрочно, пока базовая база данных поддерживается в актуальном состоянии.
Определение часового пояса в My Geocode возвращает название зоны IANA вместе со смещением от UTC и принимает конкретный момент времени, чтобы для этой точной даты применялось правильное смещение с учётом летнего времени, а не предполагалось, что сегодняшнее правило действовало всегда.