Часть I: Учебник по часовым поясам

Часовые пояса — интересная тема, потому что о них можно говорить по-разному, хотя большинство людей этого не осознают. Однако, если вы разработчик, вам лучше знать разницу.

Это первая часть серии статей о часовых поясах, состоящей из двух частей. Очередную статью цикла вы можете найти здесь.

Часовые пояса как фиксированные смещения

Мы склонны работать с двумя разными определениями часового пояса, и это может привести к путанице. Один из способов — определить часовой пояс как фиксированное смещение от всемирного скоординированного времени (UTC). Эти фиксированные смещения обычно имеют получасовые или часовые приращения (например, UTC-08:00). В разговорах эти смещения были бы очень неудобными (например, давайте проведем телефонную конференцию в 15:00 UTC-08:00, скажите что?), поэтому их часто заменяют более простыми для восприятия текстовыми метками (например, Стандартное тихоокеанское время для UTC-08:00). Эти текстовые метки, в свою очередь, сокращаются до аббревиатур часовых поясов. Эти сокращения иногда неоднозначны и требуют от говорящего достаточного контекста, чтобы устранить неоднозначность. Попробуйте организовать конференц-связь зимой между человеком в Израиле (стандартное время Израиля, IST, UTC+02) и человеком в Индии (стандартное время Индии, IST, UTC). +05:30), и посмотрите, сколько пользы вы получите, используя эти аббревиатуры.

Ситуация усложняется тем, что каждое географическое положение может выбрать любой часовой пояс («фиксированное смещение для UTC»), которое оно считает удобным. Черт возьми, каждое местоположение может даже решить провести часть своего года в одном «фиксированном смещении от UTC», а другую часть того же года в другом «фиксированном смещении от UTC». И делать это только для одних лет, а не для других. Вкратце это сложность, добавленная переходом на летнее время (DST), но также сложность, добавленная юридическими и политическими изменениями с течением времени.

Часовые пояса в зависимости от местоположения, переменные смещения

Это приводит нас ко второму определению «часового пояса». В этом втором определении «часовой пояс» — это «местное время», связанное с конкретным местоположением, но основанное на произвольных политиках, а не на географическом положении. Это определение «часового пояса» описывает переменное смещение от UTC, а не фиксированное. Во втором определении такое местоположение, как Сан-Франциско, назначается часовому поясу Тихоокеанское время (PT), но эта метка включает два фиксированных смещения — Стандартное тихоокеанское время (PST). и Тихоокеанское летнее время (PDT), которые создают второй уровень неопределенности, который может быть разрешен только после того, как у вас будет определенный момент времени для работы.

Чтобы сделать более забавный (может быть?) пример, город Гринвич, известный тем, что является родиной часового пояса Среднего времени по Гринвичу (GMT), на самом деле переводит GMT на Британское летнее время (BST) каждое лето, чтобы следить за остальной частью Великобритании в период летнего времени.

Это второе определение сложное, но его можно использовать в языках программирования, хотя и не с двусмысленными метками, описанными до сих пор. Здесь на помощь приходит IANA с базой данных часовых поясов IANA и ее идентификаторами. База данных необходима, поскольку каждый идентификатор часового пояса IANA должен отслеживать произвольную историю фиксированных смещений от UTC для эталонного местоположения, описанного этим идентификатором.

Возьмем, к примеру, ярлык Горное время. Неспециалист сказал бы, что Калгари (AB) и Финикс (AZ) находятся в часовом поясе Mountain Time (MT). Однако Калгари следует правилам провинции Альберта в Канаде (включая летние изменения для перехода на летнее время), а Феникс следует правилам Аризоны. Аризона по большей части не использует летнее время, за исключением 1918, 1942, 1943 (для всего года) и 1944. И разве что нация навахо использует летнее время, а ее территория охватывает Аризону, Нью-Мексико и Юту.

Вся эта сложность аккуратно заключена в трех идентификаторах часовых поясов IANA: America/Edmonton, America/Phoenix и America/Shiprock. Эдмонтон — столица Альберты, Феникс — столица Аризоны, но Шипрок не находится ни в Аризоне, ни в столице народа навахо. Я просто хочу сказать, что, учитывая местоположение на карте, вероятно, трудно угадать, какой правильный идентификатор часового пояса IANA использовать, поэтому не позволяйте вашим разработчикам пытаться, просто спросите своих конечных пользователей.

Часовые пояса и языки программирования

Стандартные языки программирования плохо работают с неоднозначными входными данными, поэтому аббревиатуры часовых поясов с фиксированным смещением (PST, PDT и т. д.) можно использовать только для создания удобочитаемого вывода, но не для обработки данных, описывающих моменты времени.

Временные метки можно обменивать в виде строк с прикрепленными фиксированными числовыми смещениями (но не двусмысленными метками), как в формате ISO 8601. В этом случае каждая временная метка содержит информацию о часовом поясе. Хотя это устраняет двусмысленность (и это желательное свойство для протоколов обмена данными), оно увеличивает накладные расходы.

В качестве альтернативы временные метки хранятся в виде числовых смещений от произвольного источника (например, время эпохи UNIX). Когда это происходит, информация о часовом поясе должна передаваться отдельно, и тогда идентификаторы часовых поясов IANA пригодятся. Каждая временная метка может храниться без собственной информации о часовом поясе, но данные о часовом поясе для всего набора данных могут быть однозначно восстановлены из событий, связанных с конкретным местоположением, хранящихся в небольшой базе данных.

Также обратите внимание, что если вам нужно работать только с интервалами между временными метками, вам не понадобится информация о часовом поясе.