tzfile

名前

説明

•

マジック 4バイト ASCII シーケンス は、ファイルをタイムゾーン情報ファイルとして識別します。

•

ファイルフォーマットのバージョンを識別する 1バイト(2021 時点では、ASCII NUL、 , または

•

将来使うために、15バイトの 0 が含まれています。

•

以下の順で 6 つの 4バイト整数値があります:

tzh_ttisutcnt

ファイルに記述されている UTC/local インジケータ (indicator) の個数 (UT は世界時)。

tzh_ttisstdcnt

ファイルに記述されている standard/wall インジケータの個数。

tzh_leapcnt

ファイルに記述されている閏秒データエントリの個数。

tzh_timecnt

ファイルに記述されている「遷移時間 (transition time)」データエントリの個数。

tzh_typecnt

ファイルに記述されている「ローカル時間種別 (local time types)」データエントリの個数 (0 は不可)。

tzh_charcnt

ファイルに記述されている「タイムゾーン略式文字列 (timezone abbreviation string)」のバイト数。

上記のヘッダの後には次のフィールドが続き、その長さはヘッダの内容によって異なります。

•

tzh_timecnt 昇順に並べられた 4 バイトの符号付き整数値。これらの値はネットワークバイトオーダーで記述されます。それぞれは (time(2) で返されるように)現地時間を計算する規則が変わる遷移時間として使用されます。

•

tzh_timecnt 1バイトの符号なし整数値。最後の 1つを除くそれぞれの値は、ファイルに記述されている異なるタイプのローカル時間タイプのどれが、同じインデックス付きの遷移時間から始まり、次の遷移時間を含まないまでの期間に関連付けられているかを示します(最後の時間タイプは、後述の proleptic TZ 文字列との整合性チェックのためだけに存在します)。これらの値は、次のフィールドへのインデックスとして機能します。

•

tzh_typecnt ttinfo エントリでおのおのは以下のように定義されます:

struct ttinfo {
    int32_t       tt_utoff;
    unsigned char tt_isdst;
    unsigned char tt_desigidx;
};

各構造は、 tt_utoff の場合はネットワークバイトオーダーの4バイトの符号付き整数値として記述され、その後に tt_isdst の場合は1バイトのブール値、 tt_desigidx の場合は 1 バイトの値が続きます。各構造において、 tt_utoff は UT に追加される秒数を示し、 tt_isdst は tm_isdst が localtime(3) によって設定されるべきかどうかを示し、 tt_desigidx はファイル内の ttinfo エントリに続くタイムゾーン省略バイトの配列へのインデックスとして機能します。指定された文字列が "-00" の場合、 ttinfo エントリはローカルタイムが指定されていないことを示すプレースホルダです。tt_utoff 値が -2**31と等しくなることはなく、32ビットクライアントがオーバーフローせずに補数を取れるようになります。また、現実的なアプリケーションでは、 tt_utoff は [-89999, 93599] の範囲(つまり、 -25 時間より長く、 26 時間より短い)にあります。これにより、POSIXで要求されている範囲[-24:59:59, 25:59:59]をすでにサポートしている実装で簡単にサポートできます。

•

タイムゾーン指定を表すtzh_charcnt バイトです。NULL で終了するバイト文字列で、それぞれが前述の tt_desigidx 値で索引付けされ、それぞれがタイムゾーンの略称に対応します。一方が他方の接尾辞である場合、バイト文字列は重複できます。これらの文字列のエンコーディングは指定されていません。

•

ネットワークバイトオーダーで記述された 4バイト値の tzh_leapcnt ペア。各ペアの最初の値は、非負の時間(うるう秒が発生したとき、またはうるう秒テーブルが期限切れになったときに time(2)) から返される)を示します。2 番目の値は、修正を指定する符号付き整数です。これは、指定された時間から始まる期間に適用されるうるう秒の total 番号です。値のペアは、時間で厳密に昇順にソートされます。各ペアは 1 つのうるう秒を正または負のいずれかで表しますが、最後のペアが前のペアと同じ修正を持つ場合、最後のペアはうるう秒テーブルの有効期限を表します。各うるう秒は、UTC カレンダー月の終わりにあります。最初のうるう秒は負でない発生時間を持ち、その修正が正である場合にのみ正のうるう秒になります。最初のうるう秒後の各うるう秒の修正は、正のうるう秒の場合は 1 、負のうるう秒の場合は -1 のいずれかによって前のうるう秒と異なります。うるう秒テーブルが空の場合、すべてのタイムスタンプのうるう秒修正は 0 になります。それ以外の場合、最初の発生時間より前のタイムスタンプのうるう秒修正は、最初のペアの修正が 1 または -1 の場合は 0 になり、それ以外の場合は指定されません(これは、先頭で切り捨てられたファイルでのみ発生します)。

•

tzh_ttisutcnt UT/ローカルインディケータは、それぞれ1バイトのブール値として格納され、ローカル時間タイプに関連付けられた遷移時間がUTまたはローカル時間のどちらとして指定されたかを示します。UT/ローカルインディケータが設定されている場合は、対応する標準/ウォールインディケータも設定する必要があります。

•

tzh_ttisutcnt UT/ローカルインディケータは、それぞれ 1 バイトのブール値として格納され、ローカル時間タイプに関連付けられた遷移時間がUTまたはローカル時間のどちらとして指定されたかを示します。UT/ローカルインディケータが設定されている場合は、対応する標準/ウォールインディケータも設定する必要があります。

標準/wall および UT/local インジケータは、TZif ファイルの遷移時間を、ルールのない proleptic TZ 文字列で指定された別のタイムゾーンに適した遷移に変換するために設計されました。たとえば、TZ="EET-2EEST"で TZif ファイル "EET-2EEST" がない場合、この目的のためだけに存在し、異なる UT オフセットを持つファイル "Europe/Brussels" のコピーである既知の名前 "posixrules" を持つ TZif ファイルからの遷移時間を適応させるというアイデアでした。POSIX はこの時代遅れの変換動作の詳細を指定していません。既定値ルールはインストールに依存しており、2037 を超えるタイムスタンプに対してこの機能をサポートする実装は知られていません。したがって、(例えば)ギリシャ時間を望むユーザは、より良い履歴カバレッジのために代わりに TZ="Europe/Athens" を指定し、POSIX.1-2017 以前への準拠が必要であり、古いタイムスタンプを正確に処理する必要がない場合は、TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" にフォールバックします。

 localtime(3) がゼロであるか、time 引き数がファイルに記録された最初の遷移時間より小さい場合、 tzh_timecnt は通常ファイルの最初の ttinfo 構造体を使用します。  

バージョン 2 形式

空でない場合、TZ 文字列は、8 バイトのデータ内に存在する場合、最後の遷移時間後のローカル時間タイプと一致する必要があります。たとえば、文字列 の場合、最後の遷移時間が 7月であれば、遷移のローカル時間タイプは、UTから東に 1時間の で短縮された夏時間を指定する必要があります。

TZ 文字列には、TZif ファイルの他の場所には表示されない時間帯省略形と UT オフセットを含めることができます。

また、少なくとも 1つの遷移がある場合、時間タイプ 0 は、無期限の過去から最も早い遷移時間を含まないまでの期間に関連付けられます。  

バージョン 3 形式

バージョン 4 形式

相互運用性に関する考慮事項

バージョン 1のファイルはレガシー・フォーマットとみなされ、2038 年以降の移行時間をサポートしていないため、生成する必要はありません。バージョン 1のみを理解するリーダーは、バージョン 1のデータ・ブロックの計算済の終了を超えるデータを無視する必要があります。

バージョン 1以外では、ライターはファイルのデータに必要な最も小さいバージョン番号を生成する必要があります。たとえば、ライターがバージョン 4のファイルを生成するのは、閏秒テーブルが期限切れになるか、先頭で切り捨てられる場合のみです。同様に、バージョン 4のファイルを生成しないライターは、移行時間を正確にモデル化するために TZ 文字列拡張が必要な場合のみ、バージョン 3のファイルを生成する必要があります。

バージョン 4形式の TZif ファイルの場合、最初のうるう秒レコードは、+1 でも -1 でもない修正を持つことができます。これは、TZif ファイルの先頭が切り詰められたことを表します。また、2つ以上のうるう秒遷移が存在し、最後のエントリの修正が前のエントリと等しい場合、最後のエントリは、うるう秒ではなく、うるう秒テーブルの有効期限を示します。この有効期限後のタイムスタンプは、将来のリリースで有効期限後にうるう秒エントリが追加される可能性が高いため、信頼性がありません。追加されたうるう秒は、有効期限後のタイムスタンプの処理方法を変更します。

TZif ファイルにうるう秒テーブルの有効期限が含まれている場合、TZif リーダーは有効期限後のタイムスタンプの処理を拒否するか、有効期限が存在しないかのようにタイムスタンプを処理する必要があります(おそらくエラーが表示されます)。

タイムゾーンの省略形は、 および の英数字のセットから、3～6文字の ASCII 文字で構成する必要があります。これは、タイムゾーン省略形のPOSIX要件との互換性を保つためです。

数値による時間帯の省略形は、UT オフセットと一致する必要があります。たとえば、"+0530" は UT オフセットが UT より 5.5時間進んでいる場合にのみ使用し、"-00"は UT オフセットがゼロの場合にのみ使用します。

バージョン 2以降のファイルを読み込む場合は、バージョン1のヘッダとデータブロックをスキップする目的以外は無視してください。

リーダーは、ファイルの妥当性検査の一部として、ヘッダーとデータブロックの合計長を計算し、それらがすべて実際のファイルサイズ内に収まることを確認する必要があります。

正のうるう秒が発生した場合、リーダーはうるう秒の直前の秒を含むローカル分に追加の秒を追加する必要があります。UTC オフセットが 60秒の倍数でない場合にこれが発生すると、うるう秒はローカル分の最後の秒よりも早く発生し、その分の残りのローカル秒は通常の59ではなく60までカウントされます。UTC オフセットは影響を受けません。  

一般的な相互運用性の問題

•

TZif ライタは、古い TZif リーダやバグのある TZif リーダでよくある落とし穴を避けるファイルを出力します。

•

TZif のリーダは、将来の TZif ライタによって生成されたファイルを読むときによくある落とし穴を避け、

•

将来の仕様作成者は、TZif フォーマットが変更されたときにどのような種類の問題が発生するかを確認します。

新しいバージョンの TZif フォーマットが定義された場合、設計の目標は、ファイルがリーダーの設計対象よりも新しい TZif バージョンであっても、リーダーが TZif ファイルを正常に使用できるようにすることでした。完全な互換性が達成されなかった場合、ほとんど使用されないタイムスタンプに不具合を制限し、古いバージョンのリーダーにも役立つ新しいバージョンのデータを生成するように設計されたライターで単純で部分的な回避策を可能にする試みが行われました。このセクションでは、これらの互換性の問題と回避策、およびリーダーでのその他の一般的なバグについて説明します。

TZif の相互運用性の問題には、次のようなものがあります:

•

一部のリーダーはバージョン1データのみを検査します。部分的な回避策として、ライターは可能なかぎり多くのバージョン1データを出力できます。ただし、リーダーはバージョン 1 データを無視し、リーダーのネイティブ・タイムスタンプに 32 ビットしかない場合でもバージョン 2 以上のデータを使用する必要があります。

•

バージョン 2用に設計された一部のリーダーは、バージョン3以降のファイルの最後の遷移の後にタイムスタンプを誤って処理する可能性があります。これは、proleptic TZ 文字列内の POSIX.1-2017 に対する POSIX.1-2024 拡張を解析できないためです。部分的な回避策として、ライターは必要以上の遷移を出力できるため、バージョン 2リーダーによって誤って処理されるのは遠い将来のタイムスタンプのみです。

•

一部のリーダーは、ファイルの最後の遷移の後にタイムスタンプを誤って処理する可能性があります。これは、preroleptic TZ 文字列内のすべての省略形または UT オフセットが、ファイルのタイムゾーン指定およびローカル時刻タイプ・レコードのテーブルのどこかにも存在する必要があるためです。回避策として、ライターは必要以上に多くの遷移を出力できるため、他のテーブルには preroleptic TZ 文字列の省略形とオフセットの重複が含まれます。

•

バージョン 2用に設計された一部のリーダーは、24:00 以降の移行を伴う恒久的な夏時間をサポートしていません- 例: TZ 文字列 は恒久的な東部夏時間 (-04) を示します。回避策として、ライターは 2つのタイムゾーン東を標準時に置き換えることができます。たとえば、 は、一度も使用されたことのない標準時 (XXX, -03) と年間を通じて負の夏時間 (EDT, -04) を持つタイムゾーンです。あるいは、部分的な回避策として、ライターは次のタイムゾーン東を標準時に置き換えることができます (例:恒久的な大西洋標準時 (-04) の場合は )。

•

バージョン 2または 3用に設計され、RFC 9636 への厳密な準拠を必要とする一部のリーダーは、有効期限の先頭または末尾で切り捨てられるうるう秒テーブルを持つバージョン 4ファイルを拒否します。

•

一部のリーダーはフッターを無視し、代わりに最後の遷移の時間タイプから将来のタイムスタンプを予測します。部分的な回避策として、ライターは必要以上の遷移を出力できます。

•

簡略化されたリーダーの中には、フッター以外のすべてを無視し、その proleptic TZ 文字列を使用してすべてのタイムスタンプを計算するものがあります。このアプローチは現在と将来のタイムスタンプに対して機能することがよくありますが、明らかに過去のタイムスタンプに問題があり、現在のタイムスタンプに対しても TZ="Africa/Casablanca" のような設定では失敗する可能性があります。これは、2087年までの明示的な遷移を含む TZif ファイルに対応し、その後に TZ 文字列 を含むフッターが続きます。これは、最後の明示的な遷移後のタイムスタンプにのみ使用されます。

•

一部のリーダーは、最初の遷移の前のタイムスタンプにタイムタイプ 0 を使用しません。これは、必ずしもタイムタイプ 0 を選択しないヒューリスティックを使用してタイムタイプを推測するためです。部分的な回避策として、ライターはダミー (no-op) の最初の遷移を早い段階で出力できます。

•

一部のリーダーは、-2**31 以上のタイムスタンプを持つ最初の遷移の前にタイムスタンプを誤って処理します。32 ビットのタイムスタンプのみをサポートするリーダーは、この問題が発生しやすくなります。たとえば、64 ビットの遷移を処理する場合、32 ビットで表現できるのはその一部だけです。部分的な回避策として、ライターはタイムスタンプ -2**31 にダミーの遷移を出力できます。

•

一部のリーダーは、タイムスタンプに可能な最小の符号付き 64 ビット値がある場合、遷移を誤って処理します。-2**59 未満のタイムスタンプは推奨されません

•

一部のリーダーは、 または を含む proleptic TZ 文字列を誤って処理します。部分的な回避策として、ライターは、アルファベット文字のみを含むタイムゾーンの略語に または を使用しないようにできます。

•

多くのリーダーは、非 ASCII文字を含むタイムゾーンの省略形を誤って処理します。これらの文字は推奨されません。

•

一部のリーダーは、3文字未満または 6文字を超えるタイムゾーンの略語や、英数字、 、 以外の ASCII 文字を含むタイムゾーンの略語を誤って処理する場合があります。これらの略語は推奨されません。

•

一部のリーダーは、夏時間の TZif オフセットが対応する標準時間の UT オフセットよりも小さい UT ファイルを誤って処理します。これらのリーダーは、 TZ 文字列 を表します。部分的な回避策として、ライターは TZ 文字列 と同等のデータを出力できるため、標準時間と夏時間が入れ替わります。この回避策では、年のどの部分で夏時間を使用しているかを誤って識別しますが、 UT オフセットとタイムゾーンの省略形は正しく記録されます。

•

一部のリーダーは、UTC オフセットが 60秒の倍数でない場合に発生する正のうるう秒に対してあいまいなタイムスタンプを生成します。たとえば、UTC オフセット +01:23:45 と正のうるう秒 78796801 (1972-06-30 23:59:60 UTC) の場合、一部のリーダーは 78796800 と 78796801 の両方を翌日の現地時間 01:23:46 にマッピングするのではなく、01:23:45 にマッピングし、78796815 を 01:23:60 ではなく 01:23:59 にマッピングします。1972 年にうるう秒が導入されて以来、このような UTC オフセットを観測した公的機関はないため、これはまだ実際的な問題ではありません。

いくつかの相互運用性の問題はリーダーのバグであり、ここでは主にリーダーの開発者への警告として挙げています。

•

一部のリーダは、負のタイムスタンプをサポートしていません。分散アプリケーションの開発者は、1970 年以前のデータを扱う必要がある場合、このことに留意する必要があります。

•

一部のリーダーは、非負のタイムスタンプを持つ最初の遷移の前にタイムスタンプを誤って処理します。負のタイムスタンプをサポートしていないリーダーは、この問題が発生しやすくなります。

•

一部のリーダーは、 または数字を含む のようなタイムゾーンの省略形を誤って処理します。

•

一部のリーダは、従来の -12～+12 時間の範囲外の UT オフセットを誤って処理するため、この範囲外の Kiritimati のようなロケーションをサポートしません。

•

一部のリーダーは、 UT から [-3599, -1] 秒の範囲の UT オフセットを誤って処理します。これは、オフセットを 3600 で整数除算して 0 を取得し、時間部分を として表示するためです。

•

一部のリーダーは、1時間、15分、または 1分の倍数でない UT オフセットを誤って処理します。

関連項目

Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). October 2024. Internet RFC 9636 doi:10.17487/RFC9636 .

Index

名前

説明

バージョン 2 形式

バージョン 3 形式

バージョン 4 形式

相互運用性に関する考慮事項

一般的な相互運用性の問題

関連項目