Що насправді являє собою база даних часових поясів IANA
Якщо ви коли-небудь працювали з датами та часом у програмному забезпеченні, ви покладалися на базу даних часових поясів IANA, навіть не знаючи про це. Вона відома під кількома назвами — tz database, tzdata, Olson database або zoneinfo — але всі вони позначають одне й те саме: спільний, вільно доступний каталог часових поясів світу та правил, що їх регулюють.
Слово «каталог» применшує її значення. База даних не просто перелічує, які регіони знаходяться в якому зміщенні UTC. Вона фіксує повну історію цивільного часу для кожного регіону — кожну зміну зміщення, кожен перехід на літній час, кожне воєнне переведення годинників і кожне заплановане майбутнє правило — у багатьох випадках починаючи з середини XIX століття, коли місцевий середній час поступився місцем стандартизованим поясам. Коли ваш календарний додаток правильно показує, що зустріч у 1985 році відбулася на одну годину раніше або пізніше, ніж той самий настінний час сьогодні, це робота tz database.
Вона текстова, зручна для читання людиною та невелика. Скомпільований бінарний файл, який постачається на вашому комп'ютері, займає лише кілька мегабайт. Проте вона кодує один із найскладніших наборів даних у обчислювальній техніці.
Коротка історія
Проєкт розпочався у 1980-х роках під керівництвом Артура Девіда Олсона, який зібрав першу версію та розмістив її на серверах Національних інститутів здоров'я США. Протягом десятиліть він підтримувався переважно волонтерськими зусиллями, координованими через публічний список розсилки, тому старіша назва «Olson database» досі зустрічається в документації.
Пол Еггерт став головним редактором і залишається багаторічним координатором проєкту. Його укладання супровідного документа theory.html та ретельна історія комітів зробили базу даних не лише технічним, а й історичним довідником.
У 2011 році, після короткої, але тривожної юридичної суперечки щодо історичних даних, управління перейшло до Управління з присвоєння номерів в Інтернеті (IANA) — тієї самої організації, яка координує інші основні ресурси Інтернету. IANA тепер публікує офіційні релізи, тому «IANA time zone database» стала канонічною назвою. Роботу все ще виконує та сама спільнота дописувачів; 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. Для всіх на островах цієї п'ятниці просто не існувало.
- Країни скасовують, запроваджують або переносять літній час з невеликим попередженням. Європейський Союз обговорював скасування DST; кілька країн і штатів США змінили свої правила DST в останні десятиліття. Туреччина, Росія та інші взагалі змінили свої стандартні зміщення.
- Дата початку та закінчення DST змінюється. Сполучені Штати змінили межі DST у 2007 році. Будь-яка система, яка жорстко закодувала старе правило, мовчки видавала неправильний час протягом тижнів щороку.
Якщо ви зберігаєте лише зміщення, ви не зможете відповісти на запитання «котра буде місцева година в Сантьяго 15 листопада наступного року?» — тому що відповідь залежить від правил, які можуть бути навіть не остаточно затверджені. Зберігання ідентифікатора зони (America/Santiago) разом із базою даних дозволяє програмному забезпеченню обчислити правильне зміщення для будь-якого моменту, минулого чи майбутнього, і автоматично перерахувати його, коли правила зміняться.
У цьому полягає основна цінність: tz database відокремлює ідентичність місця від правил, що постійно змінюються, які визначають його годинник.
Як вона підтримується
Підтримка відбувається відкрито. Запропоновані зміни — нове правило DST, виправлена історична дата, урядове оголошення — обговорюються в публічному списку розсилки tz, де дописувачі наводять офіційні вісники, новинні репортажі та урядові укази як докази. Точність сприймається серйозно; зміни до історичних даних, зокрема, ретельно перевіряються за першоджерелами.
Релізи версіонуються за допомогою року та літери: 2024a, 2024b, 2024c і так далі. Число — це рік; літера збільшується з кожним релізом цього року. Оскільки уряди оголошують про зміни годинників за власним непередбачуваним графіком, фіксованого ритму випуску немає — тихий рік може мати два релізи, тоді як рік політичних змін — багато. Системи повинні оновлюватися оперативно, оскільки застаріла база даних може призвести до відображення неправильного часу після набуття чинності нових правил.
Хто від неї залежить
Майже все.
- Операційні системи. Дистрибутиви Linux постачають
tzdataяк основний пакет. macOS отримує дані про зони з того самого джерела. Windows використовує власні зони на основі реєстру з історичних причин, але надає доступ до зон IANA через бібліотеку ICU та сучасні API. - Мови програмування. Фактично кожна зріла бібліотека дати/часу читає або включає tz database:
zoneinfoу Python,java.timeу Java, проєкт ICU, PostgreSQL, рушії JavaScript через ICU, Ruby, PHP та багато інших. - Додатки. Календарі, системи бронювання, платформи фінансової торгівлі, інструменти аналізу журналів і служби планування — всі вони покладаються на неї, часто без того, щоб розробники замислювалися про це.
Саме ця повсюдність робить базу даних настільки важливою. Єдине, спільне, ретельно підтримуване джерело істини означає, що зустріч, запланована в одній системі, правильно відображається в іншій, незалежно від операційних систем і мов, десятиліттями в минулому чи майбутньому.
Якщо ви хочете дослідити самі зони, перегляньте повний список часові пояси IANA або подивіться, як вони відображаються на глобусі в нашому каталозі усі часові пояси.
Часті запитання
Чи є tz database тим самим, що tzdata, zoneinfo та Olson database?
Так. Це всі назви одного проєкту. «tzdata» зазвичай стосується файлів даних, упакованих для операційної системи, «zoneinfo» — скомпільованої бінарної директорії, а «Olson database» — старіша історична назва на честь засновника Артура Девіда Олсона. Сьогодні офіційна назва — IANA Time Zone Database.
Як часто оновлюється база даних?
Фіксованого графіка немає. Релізи спричиняються реальними подіями — зміною урядом правил DST або стандартного зміщення, або виправленням історичних даних. Деякі роки мають один реліз; інші — кілька. Кожен називається як 2024a, 2024b, зі збільшенням літери протягом року.
Чому вона називає зони на честь міст, як-от America/New_York?
Міста географічно фіксовані та мають безперервну історію вимірювання часу, тоді як країни, кордони та зміщення змінюються з часом. Використання репрезентативного міста дає кожній зоні стабільний, політично нейтральний ідентифікатор, який залишається дійсним, навіть коли змінюються основні правила DST або зміщення.
Чи можу я просто зберігати зміщення UTC замість назви зони?
Тільки для одного фіксованого моменту. Для майбутніх або повторюваних подій слід зберігати ідентифікатор зони, оскільки зміщення змінюються через літній час та урядові рішення. Назва зони разом із базою даних дозволяє програмному забезпеченню автоматично обчислювати правильне зміщення для будь-якої дати.
Хто зараз керує проєктом?
Він публікується IANA, яка взяла на себе управління в 2011 році, і координується Полом Еггертом разом із спільнотою дописувачів, які працюють через публічний список розсилки tz. Технічна робота залишається спільним волонтерським зусиллям.