先確認單位與時區，再判斷事件先後
Log 裡的 Unix timestamp 不能只憑數字大小直接下結論。先用Unix timestamp 轉換工具把數值換成日期時間，確認它是秒還是毫秒，並同時查看台北、紐約、倫敦與東京的顯示時間；這樣才知道它和客服訊息、付款通知或操作紀錄是否在同一條時間線上。
Unix timestamp 是從 1970-01-01 00:00 UTC 起算的數字。這個工具會把絕對值小於 100,000,000,000 的整數當成秒，其餘整數當成毫秒。這是方便判讀的規則，不是每個系統的共同保證；遇到陌生來源，仍要查看該系統文件或同一筆事件的其他欄位。
例如付款失敗工單中有 1717200000，但通知信寫著「上午 10:00」。先換算數字，再確認通知信記錄的是哪個時區；若把秒誤當成毫秒，日期會落在很早以前，後面的排查自然全錯。不要因為兩筆紀錄相差幾小時就先假定重複扣款，時區往往才是差異來源。
用三個步驟把一串數字放回 log 時間線
先複製原始數字，不要在工單或原始 log 中直接修改。貼進工具後，記下可讀日期、顯示的時區與你判定的單位；接著回到同一次請求的 request ID、交易編號或使用者操作紀錄交叉比對。單一 timestamp 只能說明一個系統記下的瞬間，不能單獨說明誰造成問題。
- 數字約十位數時，先以「秒」作為檢查起點；約十三位數時，先檢查「毫秒」，但都要用事件上下文驗證。
- 先固定一個比較基準，例如全部以 UTC 或公司約定的營運時區整理，再保留原始時區標註。
- 核對相鄰事件：登入、送出、後端接收、第三方回應與通知寄送，不要只比較兩筆看起來最重要的紀錄。
- 記下資料來源的時鐘。不同服務若沒有同步，幾秒到幾分鐘的落差未必表示處理順序顛倒。
如果需要把某地的可讀時間和其他地區對照，可用時區轉換與會議規劃工具選擇城市和日期。它會依所選日期換算，並標示夏令時間切換時不存在的當地時間。它不會告訴你原始服務在寫入時使用了哪個時區；那必須由 log 格式、部署設定或服務文件確認。
遇到順序矛盾時，先找欄位語意而非硬改時間
有些 log 的 created_at 是排入佇列的時間，processed_at 才是完成時間；另一些會同時保存客戶端時間與伺服器接收時間。即使都能換成同一天的時刻，也不代表可以互換。先看欄位名稱與事件類型，再比較同一 request ID 的完整序列。
例如客服看到「付款失敗」在「點擊送出」之前兩分鐘，可能是瀏覽器時鐘不準、事件以不同服務時鐘寫入，或失敗訊息是先前一次嘗試留下的紀錄。把兩段文字 log 複製到文字差異比對工具可找出 request ID、狀態碼或重試次數的變化；但比對工具只呈現文字差異，無法重建分散式系統的真正因果關係。
最後做一次可重現的核對：保留原始 timestamp、單位判定、換算時區、使用的工具輸出與對應事件 ID。請另一位同事依同樣輸入重算，並確認工單敘述沒有把 UTC 寫成地方時間。這比只貼一張轉換結果截圖，更容易讓後續排查接得上。
常見問題
十位數一定是秒、十三位數一定是毫秒嗎？
通常是很實用的初步判斷，但不是保證。請將換算結果和已知事件日期比對；有些系統可能使用自訂 epoch、字串格式或截斷的精度。
為什麼換算後和同事看到的時間不同？
同一瞬間在不同時區會顯示不同鐘點。先確認兩人是否使用相同 timestamp、相同單位與相同時區，再比較結果；也要留意資料來源是否記錄夏令時間。
可以用這個工具證明事件一定先後發生嗎？
不行。工具只能把輸入數字換成時間。事件順序還要看欄位語意、request ID、服務時鐘與重試紀錄。
負數 timestamp 是錯誤嗎？
不一定。負數可表示 1970 年以前的時間；本工具接受整數輸入。若它出現在本應是近期事件的 log，才應檢查單位、欄位或資料轉換是否出錯。
能直接把客戶的完整 log 貼到工具裡嗎？
不建議。工具只需要 timestamp 數字。先移除 token、電子郵件、帳號、交易資料和其他不必要的敏感內容，再進行排查。