タイムゾーン（Timezones）

タイムゾーンが ビルド環境の一部 に含まれていない場合でも、異なるタイムゾーンでビルドした場合のビルド結果のことを考慮しなければなりません。

ビルド時のタイムゾーンを書き込まない

ツールによっては日時にタイムゾーンを含める場合があります。

$ LC_ALL=C date -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 04:14:07 +0100

UNIX時間 の形式（エポック と呼ばれています）で時刻を指定したとしても、UTC+0100 と異なるタイムゾーンで出力すると、再現性を損ねてしまう場合があります。 簡単な解決方法は、適切な環境変数を設定して、強制的にタイムゾーンを UTC にすることです。

$ LC_ALL=C date -u -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 03:14:07 +0000

専用の引数がなければ環境変数 TZ で指定できる場合があります。

$ TZ=UTC LC_ALL=C date -d'@2147483647' --rfc-2822
Tue, 19 Jan 2038 03:14:07 +0000

タイムゾーンを含まない書式にも関連する問題があります。 例えば Zip アーカイブを展開したときのファイル変更日時を維持するには、アーカイブを作成したときと同じタイムゾーンにしなければならないのです。

タイムゾーンを含む書式を使用する

“Wed, 21 Oct 2015 11:18:50” のような日時文字列には、タイムゾーンの解釈に関する曖昧性があります。

再現性のあるビルドにおいて、日時文字列にはタイムゾーンを含めるのが一番です。 代替案は UTC を前提にすることです。

何らかのタイムゾーンを指定したビルドシステムにおけるタイムゾーンを含まない日時文字列の扱いを理解するのは困難です。 例えば、サマータイムの異なるタイムゾーン同士で時間差を計算する場合など。 タイムゾーンによって方針も異なるため、ビルドを実行するときのタイムゾーンによっては、ビルドを実行する時間が伸び縮みしてしまうのです。

← Documentation index

Documentation home

Introduction

• 定義（Definitions）
• History
• やってみる（Buy-in）
• 計画する（Making plans）
• Academic publications

Achieve deterministic builds

• SOURCE_DATE_EPOCH
• 確実なビルドシステム（Deterministic build systems）
• 揮発性のある入力データは消える場合がある（Volatile inputs can disappear）
• 入力データの順序を固定する（Stable order for inputs）
• 値を初期化する（Value initialization）
• バージョン情報（Version information）
• タイムスタンプ（Timestamps）
• タイムゾーン（Timezones）
• ロケール（Locales）
• アーカイブのメタデータ（Archive metadata）
• 出力データの順序を固定する（Stable order for outputs）
• 無作為性（Randomness）
• ビルド時のファイルシステムパス（Build path）
• システムイメージ（System images）
• JVM

Define a build environment

• ビルド環境に含む要素（What's in a build environment?）
• ビルド環境を記録する（Recording the build environment）
• ビルド環境の定義における戦略（Definition strategies）
• Proprietary operating systems

Distribute the environment

• ソースコードからビルドする（Building from source）
• Virtual machine drivers
• Formal definition

Verification

• Cryptographic checksums
• Embedded signatures
• Sharing certifications
• Rebuilders

Specifications

• SOURCE_DATE_EPOCH
• BUILD_PATH_PREFIX_MAP (WIP)