日期、時間與排程

紀錄中的 10 位或 13 位時間戳記是哪一天？

使用工具

日期錯誤常從單位不明開始：把秒當毫秒，或 UTC 與當地鐘錶時間比較。正確數字也會得到奇怪日期。不要先加減偏移湊結果，應分開單位和顯示規則。

Unix 時間以明確選擇的單位讀取整數時間戳，顯示 UTC 與選定時區，不按位數自動決定。先從 0 開始，再用已知日期重現秒毫秒混淆。

輸入 0 秒，顯示時區 Asia/Tokyo

UTC:        1970-01-01T00:00:00Z
Asia/Tokyo: 1970-01-01T09:00:00+09:00

兩者是同一瞬間，東京顯示無需給 Unix 值加九小時。換時區是換鐘錶讀同一瞬間，再加九小時就同時改變瞬間，重複調整了。

只寫 2024-01-01 09:00 的日誌缺時區，無法分辨 UTC 九點還是東京九點。分享時應帶 Z、+09:00 等位移或時區名，便於重現同一瞬間。

相同數字只改單位

1704067200 seconds      → 2024-01-01T00:00:00Z
1704067200 milliseconds → 1970-01-20T17:21:07.2Z

按秒是 2024 元旦，按毫秒是 1970 年一月。同一瞬間毫秒值為 1704067200000，相差一千倍。不要試著增刪位數，應先查產生方單位。

十位秒、十三位毫秒只是常見年代的經驗，靠近 1970、負值或遠期日期位數不同。欄位叫 timestamp 也不能確定單位，API 或儲存約定應明寫。

表示同一瞬間的兩個輸入

2024-01-01T00:00:00Z
2024-01-01T09:00:00+09:00

分別反向轉換，按秒都得到 1704067200，說明是顯示區別而非瞬間位移。無位移日期可能依賴環境解讀，不宜用於可重現實驗。

含小數秒時，應區分整數秒欄位與選定單位的結果。把毫秒日誌降為整數秒會丟掉同秒內順序，應先定精度並檢查是否截位。

2024-01-01 沒有鐘錶時間與時區，轉瞬間需額外約定。為方便把生日或營業日變 UTC 零點，其他地區可能顯示前一天。純日期應按用途保留日期語意。

問日期間幾天用日曆日差，問瞬間間幾秒用經過時間。日曆一天不總是二十四小時，尤其時區轉換附近，應先明確問題再選輸入形式。

伺服器日誌相差幾秒，統一單位時區後也可能仍存在。工具只轉換時間值，不測時鐘同步或網路延遲。還應查記錄的是開始、結束、用戶端還是接收時刻。

能轉換不證明對應正確事件。檢查是否複製錯欄或產生規格變化。選一個已知事件，對照值、單位、UTC 與當地顯示以定位層次。

不要只報 1704067200，應寫 Unix 秒及 UTC 對應值，必要時附 Asia/Tokyo。缺單位或時區會迫使接收者猜測，複製結果時保留標籤。

保留 0、已知日期、秒毫秒同一瞬間與帶位移反向轉換的固定測試。只用目前時間每次結果都變，固定例更容易發現單位混淆和重複時差調整。

2024-01-01T09:00:00+09:00 與 2024-01-01T00:00:00Z 是同一瞬間，Unix 秒均為 1704067200。轉換可避免把時差當延遲。但只有秒精度的日誌不能判定同秒事件先後，乘成毫秒只是加零，不會增加原本缺失的細節。

裝置時鐘偏差也可能使正確轉換後的排序與實際相反，應結合請求 ID 和處理關係，不能只靠時間轉換斷定因果。記錄原值、秒或毫秒、顯示時區和日誌精度，將表示統一、時鐘同步、事件順序三個確認步驟分開。