Loading article…
tzデータベースは、世界のタイムゾーンと夏時間に関する規則についての共同編集物であり、主にコンピュータ プログラムやオペレーティングシステムで使用することを目的としています。[ 2 ]ポール エガートは 2005 年以来その編集者および保守者であり、[ 3 ] ICANNの組織的支援を受けています。[ 4 ] tz データベースは、 tzdata、zoneinfo データベース、またはIANA タイムゾーン データベース(インターネット割り当て番号機関にちなんで) としても知られており、創設貢献者であるアーサー デイビッド オルソンにちなんで、オルソン データベースと呼ばれることもあります。[ 5 ]
データベースのエントリの統一命名規則（America/New_YorkやEurope/Parisなど）は、ポール・エガートによって設計されました。[ 6 ]このデータベースは、 Unix タイムエポックである 1970 年以降の歴史的なタイム ゾーンとすべての市民的変更を記録しようとしています。[ 7 ]また、閏秒も記録します。[ 8 ]
データベースと一部の参照ソースコードはパブリックドメインです。[ 9 ]データベースとコードの新しい版は、変更に応じて公開され、通常は年に数回公開されます。[ 10 ]
tzデータベースでは、タイムゾーンとは、1970年以降、現地時計がすべて一致している国の地域を指します。[ 11 ]この定義は、まず、一貫した現地時計を持つ地理的な地域に関係しています。タイムゾーンは、 UTCからの特定の標準時 オフセットを持つ地域とは異なり、後者はしばしば「タイムゾーン」と呼ばれます。したがって、tzデータベースで定義されている各タイムゾーンは、標準時や夏時間などのオフセットなど、UTCからの複数のオフセットを使用する場合があります。[ 12 ]
tz データベースは、ルールとタイムゾーンの遷移を人間が読みやすい形式でリストしたテキスト ファイルのセットとして公開されています。これらのテキスト ファイルは、使用するために、タイムゾーンごとに 1 つのプラットフォーム非依存のバイナリ ファイルのセットにコンパイルされます。参照ソース コードには、 zic (zone information compiler) と呼ばれるコンパイラと、これらのファイルを読み込んで、やなどの標準APIで使用するためのコードが含まれています。localtime()mktime()
各タイムゾーンには、tzデータベースのテキストファイルのいずれかに1つ以上の「ゾーン行」があります。タイムゾーンの最初のゾーン行にはタイムゾーンの名前が記述され、それ以降のゾーン行では名前が空白のままになります。これは、前の行と同じタイムゾーンに適用されることを示しています。各ゾーン行には、日付と時刻の範囲について、標準時のUTCからのオフセット、夏時間を管理する規則セットの名前（標準時が常に適用される場合はハイフン）、タイムゾーンの略語の形式、および最後のゾーン行を除くすべてのゾーン行について、その行で管理される日付と時刻の範囲が終了する日付と時刻が指定されます。
夏時間に関する規則は、名前付きの規則セットで規定されています。各規則セットには、テキストファイル内に1つ以上の規則行が含まれています。ルール行には、それが属するルールセットの名前、ルールが適用される最初の年、ルールが適用される最後の年（1 年のみ適用される場合は「only」、その時点で有効なルールの場合は「max」）、ルールが適用される年の種類（指定された範囲のすべての年に適用される場合は「-」。ほとんどの場合がこれに該当します。それ以外の場合は、年が指定された種類であるかどうかを示すスクリプトの引数として使用される名前）、ルールが有効になる月、ルールが有効になる日（特定の日または「月の最後の日曜日」などの指定）、ルールが有効になる時刻、ルールが有効になっているときにUTC へのオフセットに追加する時間、およびタイムゾーンの略語で使用する文字（たとえば、ルールが標準時間を管理する場合は「S」、夏時間を管理する場合は「D」）が含まれます。
タイムゾーンには「エリア/場所」の形式で固有の名前が付けられています。例：「America/New_York」。英語名またはそれに相当するものを使用し、句読点や一般的な接尾辞を省略するという選択もなされました。スペースの代わりにアンダースコア文字が使用されます。場所の名前にハイフンが含まれている場合は、ハイフンが使用されます。エリア名と場所名はそれぞれ最大14文字です。[ 13 ] [ 14 ]
エリアとは、大陸、海洋、または「その他」の名前です。使用される大陸と海洋は、アフリカ、アメリカ、南極、北極、アジア、大西洋、オーストラリア、ヨーロッパ、インド洋、太平洋です。
海洋も含まれるのは、島によっては特定の大陸と結び付けるのが困難な場合があるためです。地理的にはある大陸とつながっている島もあれば、政治的には別の大陸とつながっている島もあります。大陸間の境界も参照してください。
「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年以前の期間には必ずしも当てはまりません。つまり、タイムゾーンの規則は、 1970年以前の期間において、指定された場所でのみ正しいことが保証されます。1970年以前にその地域内で時差があった場合、タイムゾーンの規則は、その期間において指定された場所でのみ適用されます。
これらは、タイムゾーンデータベースのリリースバージョン tzdata2011n 時点での、米国標準夏時間規則の規則行、米国東部時間帯（ニューヨーク市がその時間帯を代表する都市であるため「NYC」と呼ばれる）で一部の年に施行された夏時間規則の規則行、および America/New_York タイムゾーンのゾーン行です。ゾーン行と規則行は、米国における夏時間の歴史を反映しています。
# ルール 名前 開始 終了 入力 オン アット 保存 文字/文字 ルールUS 1918 1919 - 3月最終日日曜日 2:00 1:00 D ルールUS 1918 1919 - 10月最終日日曜日 2:00 0 S ルールUS 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 ルール US 2007 最大 - 3 月 日>=8 2:00 1:00 D ルール US 2007 最大 - 11 月 日>=1 2:00 0 S .... # ルール 名前 開始 終了 入力 オン アット 保存 レター ニューヨーク市ルール 1920年のみ - 3月最終日曜日 2:00 1:00 D ニューヨーク市ルール 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] アメリカ/ニューヨーク -4:56:02 - LMT 1883年11月18日 12:03:58 -5:00 米国東部時間 1920 -5:00 ニューヨーク東部標準時 1942年 -5:00 米国東部標準時 1946年 -5:00 ニューヨーク東部標準時 1967年 -5:00 米国東部標準時 複数のオフセットを持つタイムゾーン（通常は夏時間によるもの）ごとに、tzデータベースには移行の正確な時刻が記録されます。このフォーマットは、移行の日時変更にも対応できます。タイムゾーンによっては、数十年前に遡る過去のルール変更が存在する場合があります（上記の例を参照）。
ファイルzone.tabはパブリックドメインであり、ゾーンの一覧が含まれています。列と行の並べ替えについては、ファイルのコメントに以下のように記載されています。
# このファイルには、以下の列を持つテーブルが含まれています。 # 1. ISO 3166 2文字の国コード。ファイル `iso3166.tab` を参照してください。 # 2. ゾーンの主要位置の緯度と経度。 # ISO 6709符号-度-分-秒形式 で、 # +-DDMM+-DDDMM または +-DDMMSS+-DDDMMSS のいずれかです。 # 最初に緯度 (+ は北)、次に経度 (+ は東) が続きます。 # 3. TZ 環境変数の値で使用されるゾーン名。 # 4. コメント。国に複数の行がある場合にのみ存在します。 # #列は単一のタブで区切られています。 #テーブルはまず国別にソートされ、次に国の中で (1) 地理的に意味のある順序で ソートされ、 ( 2) (1) と矛盾しない場合は人口の多い地域が最初に表示されます。
1970年以前のデータは、地域を特定する都市については正確であることを目指していますが、地域全体については必ずしも正確ではありません。これは、1970年以降、時計を区別するために必要な場合にのみ新しい地域が作成されるためです。
例えば、1963年10月23日から12月9日の間、ブラジルではエスピリトサント州、グアナバラ州、ミナスジェライス州、リオデジャネイロ州、サンパウロ州のみが夏時間でした。[ 19 ]しかし、1970年以降、この地域全体で時計が同じであるという理由で、2010年にアメリカ/サンパウロからの分離要求は却下されました。[ 20 ]
ヨーロッパ/ベルリンで表されるドイツの時刻は、1945 年については正しくありません。当時、三地域圏ではベルリンとは異なる夏時間規則が使用されていました。[ 21 ]
1970年以降、2つの国によって支配されていた地域をカバーする2つのゾーンが存在する。このデータベースは、 ISO 3166-1に準拠した国の定義に従っており、その前身であるISO 3166は1974年に初めて発行された。
tz リファレンス コードとデータベースは、ボランティア グループによって維持されています。Arthur David Olson が tz リファレンス コードの変更の大部分を担当しています。Paul Eggert が tz データベースの変更の大部分を担当しています。提案された変更は tz メーリング リストに送信され、これは comp.time.tz Usenet ニュース グループにゲートウェイされています。ソース ファイルは 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ゾーンに割り当てます。[ 22 ] [ 23 ]
tzデータベースは、以下のような多くのコンピュータソフトウェアシステムにおいて、タイムゾーンの処理と変換に使用されます。
std::chrono::tzdb。Olson タイムゾーン ID は、Unicode共通ロケールデータリポジトリ(CLDR) およびUnicode 用国際コンポーネント(ICU) でも使用されています。たとえば、CLDR の Windows–Tzid テーブルは、Microsoft Windows のタイムゾーン ID を標準の Olson 名にマッピングしますが、Windows システムのタイムゾーンの数は IANA TZ データベースよりも大幅に少ないため、このようなマッピングは完全ではありません。[ 34 ]
このプロジェクトの起源は1986年以前に遡る。[ 35 ]
2011 年 9 月 30 日、データベースの著作権に関する訴訟Astrolabe, Inc. 対 Olson 他が提起されました。 [ 36 ] [ 37 ] その結果、2011 年 10 月 6 日、データベースのメーリングリストとFTPサイトが閉鎖されました。[ 38 ] この訴訟は、データベース管理者がThomas G. Shanks著のThe American AtlasとThomas G. Shanks および Rique Pottenger 著のThe International Atlasを使用したことに端を発しています。訴訟では、タイムゾーン メーリングリスト アーカイブおよびデータベースとともに維持されているいくつかの補助リンク コレクションでアトラス データが無断で複製されていると訴えましたが、実際にはデータベース自体を指摘していませんでした。この訴えは、過去のタイムゾーン データの編集のみに関係しており、既存の tzdata 世界タイムゾーン テーブルは対象外でした。[ 37 ] [ 39 ] [ 40 ]
この訴訟は、電子フロンティア財団の関与により、2012年2月22日に解決した。アストロラーベ社は、被告に訴状を送達することなく、自主的に訴訟を取り下げ、将来訴訟を起こさないという誓約に同意した。[ 41 ]
ICANNは2011年10月14日にデータベースの保守責任を引き受けた。[ 4 ] 完全なデータベースと保守計画の説明はIANAからオンラインで入手可能である。[ 42 ]
パブリック
ドメインの
タイムゾーンデータベースには、世界中の多くの代表的な場所の現地時間の歴史を表すコードとデータが含まれています。
のリリースには決まったスケジュールはありません。ただし、通常は数か月ごとにリリースされます。
各タイムゾーンは通常、従来のタイムゾーンよりも小さい地理的領域に対応しています。これは、タイムゾーン内の時計は 1970 年以降すべて一致しているのに対し、従来のタイムゾーンは現在の標準時を指定するだけだからです。たとえば、従来の北米山岳タイムゾーンの現在および将来のタイムスタンプを扱うアプリケーションは、米国式の夏時間 (DST) を採用している America/Denver タイムゾーンと、DST を採用していない America/Phoenix タイムゾーンから選択できます。また、山岳タイムゾーンの過去のタイムスタンプを扱うアプリケーションは、America/Boise、America/Edmonton、America/Hermosillo など、12 を超えるタイムゾーンから選択できます。これらのタイムゾーンはそれぞれ現在山岳時間を使用していますが、1970 年以降の一部のタイムスタンプについては他のタイムゾーンと異なります。
有効な POSIX ファイル名コンポーネント (つまり、'/' 以外の名前の部分) のみを使用してください。ファイル名コンポーネント '.' と '..' は使用しないでください。ファイル名コンポーネント内では、ASCII 文字、'.'、'-'、'_' のみを使用してください。数字を使用すると POSIX TZ 文字列との曖昧さが生じる可能性があるため、使用しないでください。ファイル名コンポーネントは 14 文字を超えてはならず、'-' で始まってはなりません。たとえば、Asia/Bandar_Seri_Begawan よりも Asia/Brunei を優先してください。例外: 下記のレガシー名の説明を参照してください。
場所をコンパクトに保つ。将来の変更で個々の場所が異なるタイムゾーンに分割されないように、国や地域ではなく、都市や小さな島を使用する。たとえば、フランスには複数のタイムゾーンがあるため、Europe/ParisをEurope/Franceよりも優先する。
タイムゾーン名の選択に使用される一般的なガイドラインを重要度の高い順に示します。...名前があいまいな場合は、あいまいさの少ない代替案を使用します。たとえば、サンホセとジョージタウンという名前の都市は多数あるため、America/San_JoseよりもAmerica/Costa_Rica、America/GeorgetownよりもAmerica/Guyanaを優先します。...地域内の場所の中で最も人口が多い場所を使用します。たとえば、Asia/BeijingよりもAsia/Shanghaiを優先します。人口が似ている場所の中から、最もよく知られている場所を選択します。たとえば、Europe/MilanよりもEurope/Romeを優先します。
名前が変更された場合は、古い綴りを「backward」ファイルに入れます。これにより、古い綴りが引き続き機能します。通常、名前の変更は、場所の共通英語綴りが変わるまれな場合にのみ行うべきです。たとえば、2008年にAsia/Calcuttaは、古い都市名の代わりに新しい都市名が長期間広く使用されていたため、Asia/Kolkataに改名されました。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク) )ECMAScript 2015 国際化 API 仕様では、IANA タイム ゾーン データベースの Zone 名と Link 名を使用してタイム ゾーンを識別します。それらの正規形式は、IANA タイム ゾーン データベースで使用されている大文字小文字の対応する Zone 名です。 ... 実装では、IANA タイム ゾーン データベースのタイム ゾーン情報を使用することが推奨されます。