Architecture Decision Recordタイムスタンプ形式
目次:
概要
課題
タイムスタンプを使用し、すべてのシステムおよびサードパーティシステム全体でうまく機能する一貫したタイムスタンプ形式を使用することで、いつ何が起きたかを追跡できるようにしたい。
私たちは、異なるタイムスタンプ形式を持つシステムと連携します:
JSON メッセージにはネイティブのタイムスタンプ形式がないため、タイムスタンプを文字列に変換し、文字列をタイムスタンプに変換する方法、つまりシリアライズ/デシリアライズの方法を選択する必要があります。
一部のアプリケーションは、UTC 時間ではなくローカル時間を使用するように設定されています。これは、ローカル時間に基づくイベントをトリガーするプロジェクトなど、ローカル時間に合わせる必要があるプロジェクトにとって便利です。
一部のシステムは、秒対ミリ秒対ナノ秒の時間分解能を使用するなど、異なる時間精度のニーズと能力を持っています。たとえば、Linux オペレーティングシステムの
dateコマンドはデフォルトの時間精度が秒ですが、Nasdaq 証券取引所はデフォルトの時間精度としてナノ秒を求めています。
決定
ナノ秒精度の ISO 8601 というタイムスタンプの標準形式、具体的には "YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ" を選択します。
この形式は、年、月、日、時、分、秒、ナノ秒、およびズールー時間帯(別名 UTC、GMT)を示します。
状態
決定済み。
詳細
前提
これらのタイムスタンプのテキスト文字列を処理し、タイムスタンプから文字列への変換(別名シリアライズ)と、文字列からタイムスタンプへの変換(別名デシリアライズ)を行う必要があります。
一般に使いやすく、変換しやすく、人間が読みやすい形式が欲しい。
分析システム、データベースシステム、金融システムなど、私たちが制御できない幅広い外部システムとの互換性が欲しい。
制約
一部のシステムには、時間精度の制限があります。たとえば、macOS オペレーティングシステムの date コマンドは、時間精度を秒で出力できますが、ナノ秒では出力できません。
ポジション
さまざまな選択肢を検討しました:
Unix エポック、つまり 1 つの増加する数値。
簡潔なテキスト形式 "YYYYMMDDTHHMMSSNNNNNNNNN"。
ローカルタイムゾーン対 UTC タイムゾーンの使用。
論拠
典型的な使用では、生の速度/サイズよりも、人間が読み書きしやすいことを重視します。
典型的な使用では、マシンシステムで問題なく機能し、サンプルデータの作成、JSON 出力の読み取り、ログファイルの grep など、手作業でもうまく機能する形式が欲しい。
高性能コンピューティングなどの非典型的な使用では、選択したテキスト形式を、プログラミング言語の組み込みの日付オブジェクト型のようなより高速な形式にテキストを変換することで最適化したくなると予想されます。したがって、HPC ではテキスト形式はあまり重要ではありません。
影響
さまざまなテキストシステムと時間システムが、この形式に収束していきます。
関連
関連する決定
時間差、別名デュレーションを追跡する、高速で簡単な方法も欲しいかもしれません。これらは Unix エポックのタイムスタンプなら簡単です。
関連する要件
Splunk、Sumo、ELK など、特定の種類のログメッセージスタンプに関する関連要件がある場合などに、決定を調整したくなるかもしれません。
関連する成果物
言語のフォーマッターとパーサー:
Rosetta Code の例:
SixArm の例:
関連する原則
容易に元に戻せる。Unix エポックなど、別の形式にかなり容易に変更できます。
早すぎる最適化を先送りする。典型的な使用では、ダッシュやコロンを使用する形式のような、数文字の追加はあまり気にしません。
メモ
ここにメモを追加。