tz データベース

tzデータベースは、世界のタイムゾーンと夏時間の遵守規則に関する情報を共同で編集したもので、主にコンピュータプログラムやオペレーティングシステムでの使用を目的としています。^[2] Paul Eggertは2005年から編集者兼管理者を務めており、^[3] ICANNの組織的支援を受けています。^[4] tzデータベースはtzdata、zoneinfoデータベース、またはIANAタイムゾーンデータベース（Internet Assigned Numbers Authorityにちなんで）とも呼ばれ、創設メンバーのArthur David OlsonにちなんでOlsonデータベースと呼ばれることもあります。 ^[5]

America/New_YorkやEurope/Parisなど、データベースのエントリの統一命名規則は、ポール・エッガートによって設計されました。^{[6]データベースは、} Unixタイムエポックである1970年以降の歴史的なタイムゾーンとすべての民間の変更を記録しようとしています。^[7]うるう秒も記録します。^[8]

データベースと一部の参照ソースコードはパブリックドメインです。^[9]データベースとコードの新しいエディションは、変更の必要に応じて、通常は年に数回公開されます。^[10]

tz データベースでは、タイムゾーンとは、1970 年以降、すべての現地時計が一致している国の地域を指します。 ^[11]この定義は、まず、一貫した現地時計を持つ地理的領域に関係します。タイムゾーンは、 UTC からの特定の標準時オフセット (「タイムゾーン」と呼ばれることが多い) を持つ地域とは異なります。したがって、tz データベースで定義される各タイムゾーンは、標準時間と 夏時間のオフセットなど、UTC からの複数のオフセットを使用する場合があります。^[12]

tz データベースは、人間が読める形式でルールとゾーン遷移をリストしたテキスト ファイルのセットとして公開されています。これらのテキスト ファイルは、プラットフォームに依存しないバイナリ ファイルのセット (タイムゾーンごとに 1 つ) にコンパイルされて使用されます。参照ソース コードには、zic (ゾーン情報コンパイラ) と呼ばれるコンパイラのほか、これらのファイルを読み取り、やなどの標準APIで使用するコードが含まれています。 localtime()mktime()

各タイムゾーンには、tz データベース テキスト ファイルの 1 つに 1 つ以上の「ゾーン行」があります。タイムゾーンの最初のゾーン行には、タイムゾーンの名前が示されます。そのタイムゾーンの以降のゾーン行では、名前が空白のままになり、前の行と同じゾーンに適用されることを示します。ゾーンの各ゾーン行では、日付と時刻の範囲、標準時間のUTC へのオフセット、夏時間(標準時間が常に適用される場合はハイフン)を管理する規則セットの名前、タイムゾーンの省略形の形式、および最後のゾーン行を除くすべての行で、その行によって管理される日付と時刻の範囲が終了する日付と時刻が指定されます。

夏時間のルールは、名前付きのルール セットで指定されます。各ルール セットには、テキスト ファイル内に 1 つ以上のルール行があります。ルール行には、ルールが属するルール セットの名前、ルールが適用される最初の年、ルールが適用される最後の年 (1 年のみ適用される場合は「only」、その時点で有効なルールの場合は「max」)、ルールが適用される年の種類 (指定された範囲のすべての年に適用される場合は「-」。ほとんどの場合に該当します。それ以外の場合は、年が指定された種類であるかどうかを示すスクリプトの引数として使用される名前)、ルールが有効な月、ルールが有効な日 (特定の日、または「月の最後の日曜日」などの指定のいずれか)、ルールが有効な時刻、ルールが有効な場合にUTC へのオフセットに追加する時間、およびタイム ゾーンの省略形で使用する文字 (たとえば、ルールが標準時間を管理している場合は「S」、夏時間を管理している場合は「D」) が含まれます。

タイムゾーンには、 「エリア/場所」という形式の固有の名前が付けられています（例：「アメリカ/ニューヨーク」）。英語名またはそれに相当するものを使用し、句読点や一般的な接尾辞を省略することも選択されました。スペースの代わりにアンダースコア文字が使用されます。場所の名前にハイフンが使用されている場合はハイフンが使用されます。エリア名と場所名はそれぞれ最大14文字です。^{[13] [14]}

エリアは、大陸、海洋などの名前です。使用される大陸と海洋は、アフリカ、アメリカ、南極、北極、アジア、大西洋、オーストラリア、ヨーロッパ、インド洋、太平洋です。

一部の島は特定の大陸と接続するのが難しいため、海洋が含まれます。一部の島は地理的には 1 つの大陸と接続され、政治的には別の大陸と接続されています。大陸間の境界も参照してください。

「Etc」の特別な領域は、いくつかの管理ゾーン、特に協定世界時を表す「Etc/UTC」に使用されます。POSIX スタイルに準拠するために、「Etc/GMT」で始まるゾーン名は、標準ISO 8601規則とは符号が逆になっています。「Etc」領域では、GMT の西側のゾーンには名前に正の符号が付き、東側のゾーンには負の符号が付きます (例:「Etc/GMT-14」は GMT より 14 時間進んでいます)。

場所とは、エリア内の特定の場所の名前です。通常は都市または小さな島です。

この方式では国名は通常使用されません。主な理由は、頻繁な政治的変更や境界変更により堅牢性に欠けるためです。大都市の名前はより永続的になる傾向があります。^[15] 通常、地域で最も人口の多い都市がタイムゾーン全体を表すために選択されますが、より広く知られている別の都市が選択され、都市以外の場所を含む別の場所が使用される場合もあります。^[16]タイムゾーンを表すために使用される場所の名前が変更された場合、将来の版では古い名前と新しい名前の両方が同じデータベースエントリを参照するようにエイリアス^[17]を作成するのが慣例です。

場合によっては、場所自体が複合名として表されます。たとえば、タイムゾーンは「America/Indiana/Indianapolis」です。3 レベルの名前には、「America/Argentina/...」、「America/Kentucky/...」、「America/Indiana/...」、および「America/North_Dakota/...」の下位の名前が含まれます。

選択された場所は、その地域全体を代表するものです。ただし、1970 年以前にその地域内で差異があった場合、タイム ゾーンのルールは指定された場所にのみ適用されます。

これらは、タイムゾーン データベースのリリース バージョン tzdata2011n 時点での、標準的な米国夏時間規則のルール ライン、一部の年に米国東部標準時ゾーン(ニューヨーク市はそのゾーンを代表する都市であるため、「NYC」と呼ばれます) で有効になっている夏時間規則のルール ライン、および America/New_York タイムゾーンのゾーン ラインです。ゾーンとルール ラインは、米国における DST の履歴を反映しています。

# ルール名 開始 終了 入力 保存 文字/秒
ルール 米国 1918 1919 - 3月 最終日 日曜日 2:00 1:00 D
統治 米国 1918 1919 - 10月 最終日 日曜日 2:00 0 S
ルール 米国 1942 のみ - 2 月 9 日 2:00 1:00 W # 戦争
ルール US 1945 のみ - 8 月 14 日 23:00u 1:00 P # 平和
ルール US 1945 のみ - 9 月 30 日 2:00 0 S
ルールUS 1967 2006 - 10月最終日日曜日 2:00 0 S
ルールUS 1967 1973 - 4月最終日日曜日 2:00 1:00 D
ルール US 1974 のみ - 1 月 6 日 2:00 1:00 D
ルール US 1975 のみ - 2 月 23 日 2:00 1:00 D
ルールUS 1976 1986 - 4月最終日日曜日 2:00 1:00 D
ルール US 1987 2006 - 4月 日>=1 2:00 1:00 D
ルール 米国 2007 最大 - 3 月 日>=8 2:00 1:00 D
ルール US 2007 最大 - 11 月 日曜日>=1 2:00 0 S
....
# ルール名 開始 終了 入力 保存 文字
ルール NYC 1920 のみ - 3 月最終日 2:00 1:00 D
ルール NYC 1920 のみ - 10 月最終日日曜日 2:00 0 S
ルール NYC 1921 1966 - 4月 最終日 日曜日 2:00 1:00 D
ルール NYC 1921 1954 - 9月 最終日 日曜日 2:00 0 S
ルール NYC 1955 1966 - 10月最終日日曜日 2:00 0 S
# ゾーン名 GMTOFF ルール フォーマット [UNTIL]
ゾーン America/New_York -4:56:02 - LMT 1883 11月18日 12:03:58
                        -5:00 米国東部標準時 1920
                        -5:00 NYC E%sT 1942
                        -5:00 米国東部標準時 1946
                        -5:00 NYC E%sT 1967
                        -5:00 米国東部時間%sT

複数のオフセット (通常は夏時間による) がある各タイムゾーンについて、tz データベースは移行の正確な瞬間を記録します。このフォーマットは、移行の日付と時刻の変更にも対応できます。ゾーンには、数十年前に遡る歴史的なルール変更がある場合があります (上記の例を参照)。

ファイルzone.tab はパブリック ドメインにあり、ゾーンをリストします。列と行のソートについては、ファイルのコメントで次のように説明されています。

# このファイルには、次の列を持つテーブルが含まれています。
# 1.   ISO 3166 2文字の国コード。ファイル「iso3166.tab」を参照してください。
# 2. ゾーンの主要位置の緯度と経度
# ISO 6709符号度分秒形式、
# +-DDMM+-DDDDMM または +-DDMMSS+-DDDMMSS のいずれか、
# 最初に緯度（+ は北）、次に経度（+ は東）。
# 3. TZ 環境変数の値で使用されるゾーン名。
# 4. コメント。国に複数の行がある場合にのみ存在します。
#
 # 列は 1 つのタブで区切られます。
# 表はまず国別に並び替えられ、次に国内の順位が
# (1) は地理的に意味があり、
# (2)は人口が最も多いゾーンを最初に配置しますが、これは(1)と矛盾しません。

1970 年以前のデータは、地域を識別する都市については正確であることを目指していますが、必ずしも地域全体については正確であるとは限りません。これは、1970 年以降の時計を区別するために必要な場合にのみ、新しい地域が作成されるためです。

例えば、1963年10月23日から1963年12月9日まで、ブラジルではミナスジェライス州、エスピリトサント州、リオデジャネイロ州、サンパウロ州のみがサマータイムを採用していました。しかし、アメリカ/サンパウロ州からの分離要請は、1970年以降、地域全体で時計が同じであるという理由で2010年に拒否されました。^[19]

ヨーロッパ/ベルリンで表されるドイツの時間は、1945年、トリゾーンがベルリンとは異なる夏時間ルールを使用していたため、正しくありません。^[20]

1970 年以降、2 つの国が管轄していた地域をカバーする 2 つのゾーンがあります。データベースは、 ISO 3166-1に従った国の定義に従っています。その前身である ISO 3166 は、1974 年に初めて発行されました。

• アジア/アデン – 1990 年までは 2 つの国:北イエメン( ISO 3166-1 : YE、首都サナア) と南イエメン(中華人民共和国、ISO 3166-1: YD、ISO 3166-3 : YDYE、首都: アデン)。
• ヨーロッパ/ベルリン– 1990 年 までの 2 か国:東ドイツ(ISO 3166-1: DD、ISO 3166-3: DDDE) と西ドイツ(ISO 3166-1: DE)

tz リファレンス コードとデータベースは、ボランティアのグループによって保守されています。Arthur David Olson が tz リファレンス コードの変更のほとんどを行っています。Paul Eggert が tz データベースの変更のほとんどを行っています。提案された変更は、comp.time.tz Usenet ニュースグループにゲートウェイされる tz メーリング リストに送信されます。ソース ファイルは、IANA FTP サーバー経由で配布されます。通常、これらのファイルはDebianなどのソフトウェア ディストリビューターによって取得され、コンパイルされた後、ソースとバイナリがそのディストリビューションの一部としてパッケージ化されます。エンド ユーザーは、ソフトウェア ディストリビューションの更新手順 (遅延が発生する場合があります) に頼るか、ソースを直接取得してバイナリ ファイルを自分でビルドすることができます。IETF は、同様の原則に基づくベスト プラクティスを文書化したRFC  6557「タイム ゾーン データベースの保守手順」を 公開しています。

タイムゾーン データベースの標準パスは、/usr/share/zoneinfo/Linux ディストリビューション、macOS、およびその他のUnix 系システムにあります。

座標セット形式の地理的境界はtzデータベースの一部ではありませんが、境界はEvan Siroky ^{[1]によって}GeoJSONおよびシェープファイル形式で公開されています。

Unicode共通ロケールデータリポジトリ(CLDR) は、tz データベース内のゾーンを参照します。ただし、ゾーンの名前は tz データベースのリリースごとに変更される可能性があるため、CLDR は、ゾーンの名前に使用されている都市のUN/LOCODEを割り当てます。または、ゾーンにそのような都市がない場合は、内部で割り当てられたコードを tzdb ゾーンに割り当てます。^{[21] [22]}

tz データベースは、次のような多くのコンピュータ ソフトウェア システムでタイム ゾーンの処理と変換に使用されます。

• FreeBSD、NetBSD、OpenBSD、DragonFly BSD、macOS、iOSなどのBSD派生システム(これらも、TZ POSIX API 実装として参照 TZ データベース処理コードを使用します)。
• GNU C ライブラリとそれを使用するシステム ( GNU、ほとんどのLinux ディストリビューション、BeOS、Haiku、Nexenta OS、Cygwinなど)。
• SolarisやUnixWareなどのSystem V Release 4派生システム。
• AIX 6.1以降^{[23] [24]}（AIX 5.2以降のAIXの以前のバージョンには、MySQLなどのサードパーティアプリケーションのサポートのためにzoneinfoが含まれています^が、^[26]、それ自体では使用されていません^{[25] [27]}）。
• アンドロイド^[28]
• IRIX、Tru64、SunOS 4.x、^[29]、UNICOS /mpを含む他のいくつかのUnixシステム。
• オープンVMS ;
• Java Runtime Environmentリリース 1.8 (2014) 以降については、java.time.ZoneId を参照してください。
• 2003 年以降のPerlモジュール DateTime::TimeZone および DateTime::LeapSecond 。
• PHP 5.1.0 (2005) 以降のリリース。
• Ruby Gem TZInfo ;
• Python標準ライブラリの zoneinfo モジュールとサードパーティの pytz パッケージ。
• 国際化のためのJavaScript言語仕様では、APIにIANAタイムゾーン名を使用することを明示的に指定し、タイムゾーンデータの使用も推奨しています。^[30]
  • 多数のライブラリも利用可能です: timezone-js、BigEasy/TimeZone、WallTime-js、moment-timezone。
• Pandas (Python) モジュール pandas – Python データ分析ライブラリ。
• .NET Frameworkライブラリ NodaTime、TZ4Net、zoneinfo ( Wayback Machineで 2017 年 12 月 24 日にアーカイブ)
• Haskellライブラリ timezone - series および timezone-olson。
• Erlangモジュールezic;
• Go標準ライブラリの time パッケージ。
• Rustクレートchrono -tz;
• Squeak Smalltalk 時間パッケージ。
• C ++ライブラリBoostとQt、およびC++20 chrono 標準ライブラリのstd::chrono::tzdb;
• DelphiとFree PascalのライブラリTZDB; ^[31 ]
• フリーの Pascalライブラリ PascalTZ;
• ツールコマンド言語には、 tzdata を使用するクロック コマンドがあります。
• Oracle 10g（2004年）以降のリリース^[32]
• PostgreSQLリリース 8.0 (2005) 以降。
• Microsoft SQL Serverライブラリ SQL Server タイムゾーン サポート
• MongoDBリリース 3.6 以降。
• pub のDart /Flutter Timezone パッケージ。
• IP クロックで使用されるファームウェアなどの組み込みソフトウェア。

OlsonタイムゾーンIDは、Unicode Common Locale Data Repository (CLDR) およびInternational Components for Unicode (ICU) でも使用されています。たとえば、CLDR Windows–Tzidテーブルは、Microsoft WindowsのタイムゾーンIDを標準のOlson名にマッピングしますが、Windowsシステムのタイムゾーンの数はIANA TZデータベースよりも大幅に少ないため、このようなマッピングは完璧ではありません。^[33]

このプロジェクトの起源は1986年以前に遡ります。^[34]

2011年9月30日、データベースの著作権をめぐってAstrolabe, Inc. v. Olson et al.の訴訟が提起された。 ^{[35] [36]} その結果、2011年10月6日、データベースのメーリングリストとFTPサイトは閉鎖された。^[37] この訴訟は、データベース管理者によるThomas G. Shanks著のThe American AtlasとThomas G. ShanksおよびRique Pottenger著のThe International Atlasの使用をめぐるものだった。タイムゾーンメーリングリストアーカイブとデータベースで管理されているいくつかの補助リンクコレクション内のアトラスデータが無許可で複製されていると訴えていたが、実際にはデータベース自体を指してはいなかった。この訴えは歴史的なタイムゾーンデータの編集のみに関するもので、現存するtzdataの世界タイムゾーンテーブルは対象としていなかった。^{[36] [38] [39]}

この訴訟は、電子フロンティア財団の関与により、2012年2月22日に解決した。アストロラーベは被告に訴状を送達することなく自主的に訴訟の取り下げを申し立て、今後訴訟を起こさないという契約に同意した。^[40]

ICANNは2011年10月14日にデータベースの保守責任を引き継ぎました。^[4] データベース全体とその保守計画の説明はIANAからオンラインで入手できます。^[41]

• tz データベースのタイムゾーンのリスト
• タイムゾーン
• 夏時間

• 法定時間(PDF)、ITU、2015 年。
• tz データベースのホームページ、UCLA(非推奨、下記の公式 IANA ソースを参照)
• tz メーリング リスト アーカイブIANAで
• IANA の tz メーリング リスト
• 「Olson/Zoneinfo/tz データベースの文学的評価」Jon Udell著

• ホームページ
• FTP
• rsync、rsync://rsync.iana.org/tz/

• zic(8) –  Linux管理および特権コマンドマニュアル(tz データベースのソース ファイルの構文を示します)
• tzfile(5) –  Linuxファイル形式マニュアル(コンパイルされた tz データベース ファイルの形式を示します)