Tz database
tz databaseとは、世界各地域の標準時（"time zone"、タイムゾーン）情報をボランティアの共同作業により収録したデータである。主にコンピュータ・プログラムやオペレーティングシステムでの利用を意図している。略称はtzdata、別名zoneinfo databaseとも呼ばれ、データベースの作成に貢献したアーサー・デイヴィッド・オルソン（Arthur David Olson）にちなみOlson databaseとも呼ばれる。ポール・エッガート（Paul Eggert）はtz databaseの編集者兼管理者である。また2011年10月からはThe Internet Corporation for Assigned Names and Numbers（ICANN）並びにInternet Assigned Numbers Authority（IANA）が管理に加わっている。
最も目に付く特徴は、ポール・エッガートにより設計されたタイムゾーンの統一的命名規則である。例えば、""や""というような表記法である。データベースは、歴史的な（経年変化を記録した）タイムゾーンならびに1970年のUNIXエポックタイム（1970年1月1日0時0分0秒 UTC）からの、民間における全ての変更を記録するよう企図されている。また、夏時間のような標準時の変化を示す"遷移"（"transition"）情報も含まれ、閏秒でさえも記録されている。
プロジェクトの起源は少なくとも1986年にまで遡る。データベース構築のためタイムゾーンや夏時間の履歴を調査するのに現在も使用している重要な情報源は、（Thomas G. Shanks）により"ACS publications"から1978年以降数版刊行されているアトラス、The American Atlas並びにシャンクスとリック・ポッテンジャー（Rique Pottenger）によるThe International Atlasである。幾つかの参照用ソースコードも含め、プロジェクトのデータベースはパブリックドメインに置かれている。概ね年に数回、変更が必要となる場合にデータベースの新版が公開される。
2011年9月30日、本データベースの著作権に関連する訴訟が提起された（「"アストロレーブ・インコーポレイティッド対オルソン他事件"」 "Astrolabe, Inc. v. Olson et al."）。その結果、2011年10月6日（UTC）、tz databaseの維持管理並びに頒布の停止がオルソンより発表された。同時にメーリングリストの閉鎖も発表され、最新のアーカイブが配置されていたNIH内のFTPサイトの運営は停止した。オルソンのメールによると、「今回の閉鎖はtz databaseに関連する民事訴訟が同年9月30日に提起され」訴訟係属（"pending legal case"）にある為と述べている。一方に提出された申立訴状（"complaint text"）によると、原告は""ACS Atlas""のデータを自社ソフトウェアに利用する企業、アストロレーブ（"Astrolabe"）であり、「tz databaseがアストロレーブが持つ著作権を侵害（"copyright infringement"）した」と主張している。
訴状によると、本件は先に述べた通りtz databaseが参考として使用している2つのアトラス、"The American Atlas"と"The International Atlas"をtz databaseメンテナが著作物として利用したか否かという点が主な争点となる。とりわけ「tzメーリングリスト・アーカイブ」（タイムゾーン・メーリングリスト・アーカイブ。管理についての詳細は、節「管理」を参照）並びに当該データベースと共に維持管理されているいくつかの「補助的な連結収集物」（"auxiliary link collections"）に、アトラスの「データ」が「無断転載」（"unauthorized reproduction"）されたと原告は主張している。しかし、当該データベース自体は実際には申立の対象としてはなっていない。この申立ではタイムゾーン・データの経年変化を記録する「編集物」（"compilation"）のみが関係しており、現行のtz databaseの全世界のタイムゾーンを記録したテーブルは対象となっていない。
tz databaseは、構成ファイルのコメント・テキストを見れば分かる通り、タイムゾーン・データの利用の程度を検証できるよう、当該アトラスを含む情報源を明らかに参照している。このアトラスはtz databaseの構築に都合の良い（好ましい）情報源の一つである。そして当該データベースにアトラスから複製された「事実に基づくデータ」（"factual data"）が多く含まれている。著作権は通常「事実」（"fact"）に付随するものではないが、「創作的表現」（"creative expression"）に対しては発生し得るものであり、当該データベースは当該アトラスの断片を引用したのではなく、主としてタイムゾーン・データを独自の形式（フォーマット）で「複製した」（"reproduce"）のであり、一目見て訴訟申立の根拠は薄弱であると批判されている。加えて、タイムゾーン・データベース全体としても「著作性」（"copyrightable"）はない。その理由は、たとえタイムゾーン・データをアトラスに纏め上げるのに著しい作業量を伴うとしても、アトラスに掲載された情報は完全な事実の収集であり、それ故創作性は無いからである、とのあり方から見て通常結論付けられる。
2012年2月22日にアストロレーブはタイムゾーンデータが歴史的事実であることを認め、訴訟を取り下げた。
2011年10月14日、本データベースの管理はICANNへと引き継がれた。IANAはウェブページにて、著作権侵害の申立を受けているデータも含む完全なデータベースのコピーをオンライン上で公開しており、データベースの管理に関する現行ならびに今後の計画も同時に発表している。
tz databaseはテキストファイルとして公開される。そのファイルは、人が可読な形式であり、ルールとタイムゾーンの遷移情報が一覧化されている。利用に当たっては、プラットフォーム独立なバイナリファイルにコンパイルされる。バイナリファイルはタイムゾーン毎に1つずつ生成される。参照用ソースコードにはzic（zone information compiler）と呼ばれるコンパイラが付属しており、同時に、関数codice_1や
codice_2といった標準的なAPIを利用してコンパイル済みデータを読み込んだり、利用することができるコードも付属している。これらタイムゾーンの標準的なAPIは標準Cライブラリをはじめとして多くのライブラリに採用されている。とりわけ標準Cライブラリはtz databaseの標準時データをテキスト生データからタイムゾーンコンパイラでコンパイルしてからデータをロードする。前述のzicは現在では参照用ソースコードには同梱されておらず、各ライブラリ毎に収録されている。GNU Cライブラリ（glibc）とその派生物ではtz databaseのzicそのもの、またはそれと同様のタイムゾーン・コンパイラを収録している。GNU/LinuxシステムやBSD系システムでは、オペレーティングシステム・インストール時もしくは、適宜ユーザの指示によりシステム時刻の標準時を指定できる。概ねUTCまたはシステムが設置されている地域の標準時などその他任意の標準時を指定できる。設定の後システムは前述の通りタイムゾーン・テキストをコンパイルする。よってこの場合tz databaseのアップグレードを行う度にコンパイルし直す必要があるが、概ね現代的なパッケージ管理システムは標準Cライブラリもしくはtz databaseを含むパッケージのアップグレード時に自動的に生テキストデータを再コンパイルする。組み込みLinuxなどのメモリの少ない環境では、コンパイル処理に時間がかかるため、コンパイル済みのパッケージを利用する場合もある。Debian 6.0（コードネーム; squeeze）などではこの方法を採用している。
tz databaseにおいて「タイムゾーン」（""time zone""）とは、1970年以来ずっと地域内の全ての時計が合っているような、国における地域のことである。。この定義は、一貫した地方時を持つ地理的地域とまず最初に関係がある。これはグリニッジ子午線からの一貫した差分と関係がある他の定義とは異なる。それゆえ、tz databaseにより定義された各タイムゾーンは、場合によってはUTCからの時間の差分（協定世界時との差）を複数持つ。典型的には、標準時と夏時間双方が同一のタイムゾーンに含まれる。
タイムゾーンは人間が理解しやすいようにするため、例えば"America/New_York"といったような""地域"/"地名""形式の固有の名称を持っている。また、その選択は英語名もしくはそれと等価な名前を利用するようになっており、名称の句読点や共通の接尾辞は省かれる。アンダースコアはスペースの代わりに利用される。地名部分におけるハイフンはそのまま用いられる。
「"地域"」（""Area""）とは、大陸名、大洋名、もしくは""Etc""という特殊な名前のいずれかを指す。大陸名と大洋名一式には現在、次が含まれる。アフリカ（Africa）、アメリカ（America）、南極（Antarctica）、北極（Arctic）、アジア（Asia）、大西洋（Atlantic）、オーストラリア（Australia）、ヨーロッパ（Europe）、インド（Indian）、太平洋（Pacific）。
"Etc"という特殊な地域は、幾つかの管理されるタイムゾーン、とりわけUTCを表す"Etc/UTC"のために使用される。POSIX形式、SUSに従うため、"Etc/GMT"を始めとするこれらのタイムゾーン名は、多くの人の予想とは正反対となる符号を持つ（比較のため、UTCのオフセットも参照せよ）。この形式では、タイムゾーン名の符号に関して、GMTから見て西側のタイムゾーンは、正の符号、東側は負の符号を持つ。例えば、tz databaseのタイムゾーン名"Etc/GMT-14"はGMTから14時間進んでいる、換言すれば、UTCから14時間分東のタイムゾーンに位置する（子午線から東回りに経度210度分進めたタイムゾーンに位置する）。すなわち、UTC+14と同じタイムゾーンを指している。
「"地名"」（""Location""）とは、該当地方内の特定の地名を指し、大抵都市や小規模な島嶼に当たる。このスキームにおいては国名は使用されない。主な理由として、政治的な変更や国境変更は頻繁にあるため国名を利用するスキームではデータの更新作業が煩雑になることが挙げられる。大都市の名前はより永続的な傾向がある。しかしながら、データベースの管理者は、ISO 3166-1 alpha-2国名コードのそれぞれにおいて、少なくとも1つのタイムゾーンを含むようにしており、そして、データベースへのユーザインタフェースの多くはこのことを利用している。加えて、将来タイムゾーンが変更された際に地域が異なるタイムゾーンに分断されないように地名の選択は地理的にコンパクトになるよう望まれている。
通常、地名には、全体のタイムゾーンを代表するある地方の人口の最も大きい都市が選択される。しかしながら、幅広く知られている名前やより曖昧ではない名前を持つその他の都市が存在する場合、そちらが選択される可能性がある。都市名が変更されたという場合においては、旧名と新規の名称双方が同じデータベース・エントリを指し示すようにするため、将来のバージョンにおいて「別名」（""alias"", "エイリアス"）を作成するという慣習がある。
時には「"地名"」がそれ自身、複合的な名称で表現される場合がある。""というタイムゾーンがそのような例である。このような3段階形式の名称は現在、"America/Argentina/..."、"America/Kentucky/..."、"America/Indiana/..."、そして"America/North_Dakota/..."以下のゾーンにのみ存在する。
選択された地名は完全なその地域の代表となる。そのため、すべての都市名がその名にちなんで命名されるタイムゾーンを持つとは限らない。例えば、"America/Boston"というタイムゾーンは存在しない。更に、現時点で所属するタイムゾーンが同一であるが互いに異なる都市は、歴史的な意味で別名が付けられている場合（例えば、同じ標準時である"America/Detroit"と"America/New_York"の違い）や、または同じタイムゾーンに属するが異なる別々の都市が歴史的な意味で異なる国に分断された場合（例えば、旧チェコスロバキアの分裂による"Europe/Prague"と"Europe/Bratislava"の違い）により、たとえ現時点ではタイムゾーンが一致しているにも関わらず、将来異なるタイムゾーン名を持つ可能性もある。
2010年5月1日、アーサー・デイヴィッド・オルソンは地名の文字数の限度を14に定めることを述べている。その理由は例えば（Bahía de Banderas）のような地名から"de"を削り、識別子を"Bahia_Banderas"（データベース上では）のみに限定することを正当化するためである。
tz databaseにはかつて誤ったタイムゾーンが含まれていたケースがあった。とりわけ日本標準時における誤りについては、記事"日本標準時#South Ryukyu Islands時間"等を参照されたい。これは前述した"The International Atlas"の第3版に誤った記述が含まれていたため起こった。
大抵は標準時と夏時間の遷移のことを指すが、UTCからの複数の時間差分を持つ各タイムゾーン向けに、tz databaseは時刻の遷移を正確に記録している。このフォーマットは、遷移の日時の変化も適宜調節できる。
はパブリックドメインに置かれているファイルである。このファイルにはタイムゾーンが一覧で記述されている。列、行が表す区分はファイル内のコメントに次のように記述されている。
参考訳:
1970年より以前のデータに関しては、地域のタイムゾーンを同定する都市名を修正するよう注意を払っている。しかし、必ずしも地域全体でそのような修正が必要とは限らない。なぜなら1970年時点からの標準時を区別する場合にのみ、新しい地域が作成されるからである。
例えば、1963年10月23日から1963年12月9日までブラジル、ミナスジェライス州、エスピリトサント州、リオデジャネイロ州、サンパウロ州は夏時間制度を採用していた。しかし、1970年からの標準時はこの地域全体では同一であったため、タイムゾーンを分割する要求は却下された。
ドイツ時間の例では、トライゾーン内でベルリンと異なる夏時間を採用していた1945年に関しては、タイムゾーンは正しい時刻を示していないとされる。
1970年以後において、2つの国に及ぶ地域を含むタイムゾーンが2つ存在する。tzdataはISO 3166-1の規格通りの国ならびに国名コードの定義に従っている（ISO 3166-1はその先行規格、ISO 3166を1974年に初めて公開している）。
tz databaseのコードとデータベース本体は、ボランティア集団により管理されている。アーサー・デイヴィッド・オルソンはコードへ、ポール・エッガートはデータベースに、それぞれ最も多くの変更を加えた人物である。提案された変更点は、tzメーリングリストに送付される。このメーリングリストは、Usenetニュースグループのcomp.time.tzにゲートウェイを提供している。ソースコードはFTPサーバのcodice_3を経由して頒布される。一般に、これらのファイルはDebianのようなソフトウェア・ディストリビューターに採用され、事前コンパイルを行い、ソースコードとバイナリパッケージがディストリビューションの一部として収録される。エンドユーザーは、いくらか遅延を伴うものの、これらソフトウェア・ディストリビューションのアップデート手続きを頼りにするか、直接 ftp://elsie.nci.nih.gov/pub/ からソースコードを入手して、バイナリファイルを自分でビルドするかどちらかの手段をとることができる。
現在の管理から将来、類似の方針を基にIANAによる管理へと移行する計画がIETFにより策定中である。これはHTTPベースの通信プロトコルを利用する仕組みを持つとされる。
訴訟提起に基づき（"Pursuant to a lawsuit"）、オリジナルの頒布用FTPサーバとメーリングリストは閉鎖された。2011年10月7日、ICANNの有志（ら）によりメーリングリストのアーカイブが複製され、一時的に仮メーリングリストが開設された。このメーリングリストは引き続きタイムゾーンのメンテナンスの為に利用される。2011年10月14日、IETFから要請を受け、正式にICANNが管理を引き継ぐと発表した。IETF議長ラス・ハウズリー（Russ Housely）は、商用システムを含む様々なソフトウェアでtz databaseが使用されている以上（注: 節"ソフトウェア・システムにおける利用"を参照）、管理が滞ることで起こりえる影響は計り知れない」と述べている。2011年10月現在、tz databaseはタイムゾーン・コンパイラ等のツール（"tzcode"）と生テキストのデータベース本体（"tzdata"）双方がICANN、IANA管理下のFTPサーバで頒布されている。
Linuxディストリビューションをはじめとする多くのUnix系システムにおいて、タイムゾーンデータが格納されている標準的なディレクトリパスは/usr/share/zoneinfo/である。ファイルの形式識別用コマンドであるは、次の実行例のように、バイナリ形式のタイムゾーンファイル内部からデータを読み出し、人間が理解しやすいテキスト形式で表示する機能をサポートしている。
codice_4
経緯度に基づく地理的な「境界線」（国境線ではない）の情報はtz databaseの一部ではない。しかしながら、境界線に関する情報は存在し、エリック・ミュラー（Eric Muller）が、tzdataに収録されている「タイムゾーンに関する『境界線』」をベクター図形のイメージに表現したものを一般に公開している（上図）。このベクター図形を利用すると、地球上の経緯度上の各地点に位置づけられる、tzdata上のタイムゾーンを決定できる。
CLDRはUN/LOCODEを地域同定に利用している。この実装は全ての識別子が国家を参照しており、tz databaseの開発元が避けたいと思っている事項も含まれている。
tz databaseは多くのコンピュータシステム上でタイムゾーン処理とタイムゾーン変換のために利用されている。以下のような例が挙げられる。その他、Olson timezone IDというものがユニコードコンソーシアムのCLDR並びにで利用されている。例えば、「CLDR Windows → Tzid」テーブルは、Microsoft Windows time zone IDsから標準的Olson名へのマッピングを行う。
Unix系システムにおいて、環境変数TZにtz databaseのタイムゾーンを指定しdateコマンドの出力結果が変化する様子を示す。シェルのロケールは日本（例: 環境変数LANG=ja_JP.UTF-8など）に指定されているものとする。またOSのインストール時に指定したタイムゾーンは日本標準時であるものとする。タイムゾーン設定はGNU Cライブラリでは/etc/localtimeファイルに保存され、コンパイル済みタイムゾーンデータは/usr/share/zoneinfoディレクトリ以下に保存されることが多いとされる。
dateコマンドは引数に何も指定しないで実行した場合、デフォルトではシステム時刻と/etc/localtimeのシステム・タイムゾーン設定を検知し両者を表示する。
日本標準時を明示的に指定する場合は以下となる。
フランスは中央ヨーロッパ時間（CET）を採用している。TZに指定した場合の結果は以下となる。
フランスでは4月は夏時間施行期間であるため、3ヶ月後は、
POSIX形式では、グリニッジ子午線の西回りを正の符号で表記する。符号に注意せよ。
TZに無効な文字列を指定した場合、すべて協定世界時（UTC）であると見なされる。
よくある間違いはTZにJSTと指定してしまうことである。これだとTZにUTCを指定した場合と同じになってしまう。POSIXのTZ環境変数の表記に合わせるならば、JST-9と指定しなければならない（符号の正負に注意せよ）。tz databaseの作者はtz databaseが利用できる環境ならば、このようなPOSIX表記を利用せずとも、最初に挙げたAsia/Tokyoのような"Area/Location"表記を利用した方が誤りを軽減できると述べている。