Architecture Decision Record時間戳格式
目錄:
摘要
問題
我們希望透過使用時間戳,並使用在我們所有系統和第三方系統中都能良好運作的統一時間戳格式,來追蹤事情發生的時間。
我們要與具有不同時間戳格式的系統互動:
JSON 訊息沒有原生的時間戳格式,因此我們需要選擇如何將時間戳轉換為字串,以及如何將字串轉換為時間戳,即如何序列化/反序列化。
有些應用被設定為使用本地時間,而不是 UTC 時間。這對於必須適應本地時間的專案來說可能很方便,例如觸發基於本地時間的事件的專案。
有些系統對時間精度有不同的需求和能力,例如使用秒、毫秒或納秒的時間解析度。例如,Linux 作業系統的
date命令預設使用秒級時間精度,而納斯達克證券交易所則要求預設使用納秒級時間精度。
決策
我們選擇具有納秒精度的 ISO 8601 標準時間戳格式,具體為“YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ”。
該格式顯示年、月、日、時、分、秒、納秒以及 Zulu 時區(又稱 UTC、GMT)。
狀態
已決定。
詳情
假設
我們需要處理這些時間戳文字字串,即把時間戳轉換為字串(又稱序列化),並把字串轉換為時間戳(又稱反序列化)。
我們希望格式總體上易於使用、易於轉換,並且便於人閱讀。
我們希望與大量無法控制的外部系統相容,例如分析系統、資料庫系統和金融系統。
約束
有些系統存在時間精度限制。例如,macOS 作業系統的 date 命令可以以秒為單位列印時間精度,但不能以納秒為單位。
立場
我們考慮了一系列選項:
Unix 紀元(epoch),即一個不斷遞增的數字。
簡潔的文字格式“YYYYMMDDTHHMMSSNNNNNNNNN”。
使用本地時區還是 UTC 時區。
論證
對於典型的使用,我們更看重便於人閱讀/書寫,而不是原始速度/體積。
對於典型的使用,我們希望格式在機器系統中執行良好,同時也便於手動操作,例如編寫範例資料、閱讀 JSON 輸出、用 grep 搜尋日誌檔案等。
對於非典型的使用,例如高效能運算,我們預計會希望透過將文字轉換為更快的格式(例如程式語言內建的日期物件型別)來最佳化我們所選擇的任何文字格式。因此,文字格式對高效能運算(HPC)來說並不太重要。
影響
我們各種文字系統和時間系統將趨於採用這一格式。
相關內容
相關決策
我們可能還希望有一種快速/簡便的方式來追蹤時間差,即持續時間。使用 Unix 紀元時間戳很容易做到這一點。
相關需求
如果我們有對特定型別日誌訊息戳的相關需求(例如用於 Splunk、Sumo、ELK 等),我們可能需要調整我們的決策。
相關製品
語言的格式化和解析工具:
Rosetta Code 範例:
SixArm 範例:
相關原則
易於撤銷。我們可以很容易地改用其他格式,例如 Unix 紀元。
推遲過早最佳化。對於典型的使用,我們並不太在意多出幾個字元,例如使用短橫線和冒號的格式。
備註
在此新增備註。