Что на самом деле представляет собой База данных часовых поясов IANA
Если вы когда-либо работали с датами и временем в программном обеспечении, вы полагались на Базу данных часовых поясов IANA, знали вы об этом или нет. Она известна под несколькими именами — tz database, tzdata, база данных Олсона или zoneinfo — но все они относятся к одному и тому же: совместно поддерживаемому, свободно доступному каталогу мировых часовых поясов и правил, которые ими управляют.
Слово «каталог» не передаёт всей сути. База данных не просто перечисляет, какие регионы находятся в каком смещении от UTC. Она фиксирует полную историю гражданского времяисчисления для каждого региона — каждое изменение смещения, каждый переход на летнее время, каждый сдвиг часов во время войны и каждое запланированное будущее правило — во многих случаях до середины XIX века, когда местное среднее время уступило место стандартизированным часовым поясам. Когда ваше календарное приложение правильно показывает, что встреча в 1985 году произошла на час раньше по сравнению с тем же астрономическим временем сегодня, это работа базы данных tz.
Она текстово-ориентирована, читаема человеком и мала. Скомпилированная двоичная форма, которая поставляется с вашим компьютером, весит всего несколько мегабайт. И всё же она кодирует один из самых тихо сложных наборов данных в вычислительной технике.
Краткая история
Проект начался в 1980-х годах под руководством Артура Дэвида Олсона, который собрал первую версию и разместил её на серверах Национальных институтов здравоохранения США. На протяжении десятилетий он в значительной степени поддерживался силами волонтёров, координируемых через публичный список рассылки, поэтому старое название «база данных Олсона» всё ещё встречается в документации.
Пол Эггерт стал главным редактором и остаётся давним координатором проекта. Его составление сопроводительного документа theory.html и тщательная история коммитов превратили базу данных в столько же исторический справочник, сколько и технический.
В 2011 году, после краткого, но тревожного юридического спора об исторических данных, управление перешло к Управлению по присвоению номеров в Интернете (IANA), тому же органу, который координирует другие основные интернет-ресурсы. IANA теперь публикует официальные релизы, поэтому «База данных часовых поясов IANA» стала каноническим названием. Работу по-прежнему выполняет то же сообщество участников; IANA предоставляет институциональный дом и стабильную точку распространения.
Соглашение об именовании: Area/Location
Одна из самых отличительных особенностей базы данных — это то, как она называет часовые пояса. Вместо названий стран или сырых смещений используется формат Area/Location, почти всегда привязанный к репрезентативному городу:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
«Area» обычно является континентом или океаном (America, Europe, Asia, Pacific), а «Location» — известным городом в этом часовом поясе. Такой выбор кажется необычным, пока вы не поймёте причину, стоящую за ним.
Города стабильны; политические границы и смещения — нет. Страны разделяются, объединяются, переименовываются и меняют свои часы. Город, напротив, является фиксированной географической точкой с непрерывной историей времяисчисления. Называть часовой пояс America/New_York вместо «US Eastern Time» или «UTC-5» означает, что идентификатор остаётся действительным, даже когда правила, привязанные к нему, меняются.
База данных также намеренно избегает названий стран, чтобы обойти политические споры и потому, что одна страна часто содержит несколько часовых поясов — у Соединённых Штатов их более дюжины. Она выбирает наиболее населённый или исторически значимый город в каждом отдельном часовом поясе в качестве нейтральной метки. Когда два региона имеют одинаковую историю часов с 1970 года, они делят один часовой пояс; как только их истории расходятся, они получают отдельные записи.
Почему сырых смещений недостаточно
Распространённый инстинкт новичка — хранить время как «UTC+5:30» и считать дело сделанным. Это работает для одного момента, но перестаёт работать, как только вам нужно рассуждать о будущих или повторяющихся событиях, потому что смещения не являются статическими свойствами места. Они являются результатом правил, которые правительства постоянно и часто внезапно меняют.
Рассмотрим несколько реальных примеров, которые базе данных пришлось усвоить:
- Самоа полностью пропустило 30 декабря 2011 года. Чтобы синхронизировать свой рабочий день с Австралией и Новой Зеландией, а не с Соединёнными Штатами, Самоа перепрыгнуло через линию перемены даты, перейдя с UTC-11 на UTC+13. Для жителей островов эта пятница просто не существовала.
- Страны отменяют, вводят или переносят летнее время с небольшим предупреждением. Европейский Союз обсуждал отмену летнего времени; несколько стран и американских штатов изменили свои правила летнего времени за последние десятилетия. Турция, Россия и другие полностью изменили свои стандартные смещения.
- Даты начала и окончания летнего времени меняются. Соединённые Штаты перенесли границы летнего времени в 2007 году. Любая система, которая жёстко запрограммировала старое правило, молча выдавала неверное время в течение нескольких недель каждый год.
Если вы храните только смещение, вы не сможете ответить на вопрос «какое местное время будет в Сантьяго 15 ноября следующего года?» — потому что ответ зависит от правил, которые могут быть ещё даже не окончательно утверждены. Хранение идентификатора часового пояса (America/Santiago) вместе с базой данных позволяет программному обеспечению вычислять правильное смещение для любого момента, прошлого или будущего, и автоматически пересчитывать его при изменении правил.
В этом и заключается основная ценность: база данных tz отделяет идентичность места от постоянно меняющихся правил, определяющих его часы.
Как она поддерживается
Поддержка происходит открыто. Предлагаемые изменения — новое правило летнего времени, исправленная историческая дата, правительственное объявление — обсуждаются в публичном списке рассылки tz, где участники ссылаются на официальные бюллетени, новостные сообщения и правительственные указы в качестве доказательств. Точность принимается всерьёз; изменения исторических данных в частности тщательно проверяются по первоисточникам.
Релизы версифицируются годом и буквой: 2024a, 2024b, 2024c и так далее. Число — год; буква увеличивается с каждым выпуском в этом году. Поскольку правительства объявляют об изменениях часов по своему непредсказуемому графику, фиксированного графика выпуска нет — в тихий год может быть два релиза, а в год политической турбулентности — много. Ожидается, что системы будут обновляться своевременно, так как устаревшая база данных может означать отображение неверного времени после вступления в силу нового правила.
Кто от неё зависит
Практически всё.
- Операционные системы. Дистрибутивы Linux поставляют
tzdataкак основной пакет. macOS берёт данные о часовых поясах из того же источника. Windows использует свои собственные зоны на основе реестра по историческим причинам, но предоставляет доступ к зонам IANA через библиотеку ICU и современные API. - Языки программирования. По сути, каждая современная библиотека для работы с датой/временем читает или включает базу данных tz:
zoneinfoв Python,java.timeв Java, проект ICU, PostgreSQL, движки JavaScript через ICU, Ruby, PHP и многие другие. - Приложения. Календари, системы бронирования, торговые платформы, инструменты анализа журналов и сервисы планирования — все полагаются на неё, часто не задумываясь об этом разработчики.
Именно эта повсеместность и делает базу данных настолько важной. Единый, общий, тщательно поддерживаемый источник истины означает, что встреча, запланированная в одной системе, правильно отображается в другой, на разных операционных системах и языках, за десятилетия в прошлое или будущее.
Если вы хотите изучить сами часовые пояса, просмотрите полный список часовые пояса IANA или посмотрите, как они наносятся на карту мира в нашем каталоге все часовые пояса.
Часто задаваемые вопросы
Являются ли tz database, tzdata, zoneinfo и база данных Олсона одним и тем же?
Да. Это всё названия одного и того же проекта. «tzdata» обычно относится к файлам данных, упакованным для операционной системы, «zoneinfo» — к скомпилированному двоичному каталогу, а «база данных Олсона» — это более старое историческое название в честь основателя Артура Дэвида Олсона. Сегодня официальное название — База данных часовых поясов IANA.
Как часто обновляется база данных?
Фиксированного графика нет. Релизы запускаются реальными событиями — изменением правил летнего времени или стандартного смещения правительством, или исправлением исторических данных. В некоторые годы выходит один релиз; в другие — несколько. Каждый имеет название вида 2024a, 2024b, с увеличением буквы в течение года.
Почему она называет часовые пояса в честь городов, например America/New_York?
Города географически фиксированы и имеют непрерывную историю времяисчисления, тогда как страны, границы и смещения меняются со временем. Использование репрезентативного города даёт каждому часовому поясу стабильный, политически нейтральный идентификатор, который остаётся действительным даже при изменении правил летнего времени или смещения.
Могу ли я просто хранить смещение UTC вместо названия часового пояса?
Только для одного фиксированного момента. Для будущих или повторяющихся событий вам следует хранить идентификатор часового пояса, потому что смещения меняются из-за летнего времени и правительственных решений. Название часового пояса вместе с базой данных позволяет программному обеспечению автоматически вычислять правильное смещение для любой даты.
Кто сейчас управляет проектом?
Он публикуется IANA, которая взяла на себя управление в 2011 году, и координируется Полом Эггертом с сообществом участников, работающих через публичный список рассылки tz. Техническая работа остаётся совместным волонтёрским усилием.