epoch 轉換器指南:轉換紀元時間、Unix 時間和時間戳
聚焦正確使用 epoch 轉換器的指南:把 epoch 轉日期、日期轉 epoch、Unix 時間轉人類時間、毫秒轉日期,提供 UTC 和本地時區輸出,且不混用單位。
epoch 轉換器的作用
epoch 轉換器把數字時間戳轉換為可讀日期,並把人類日期轉換回 epoch 時間戳。好的轉換器能處理 Unix 秒、Unix 毫秒、UTC 輸出、本地時區輸出與 ISO 8601 字串,並在你把值複製到程式碼、資料庫或 API 請求之前明確單位。epoch 轉換器、epoch 時間轉換器、Unix 時間轉換器、Unix 時間戳轉換器與 Unix 紀元計算機這些說法都指同一件事:在自 1970 年 1 月 1 日 UTC 起的秒(或毫秒)計數與人類可讀日期之間互轉。
先確定方向
大多數時間戳任務是兩個方向之一:epoch 轉日期,或日期轉 epoch。先確定方向可避免錯誤測試資料與損壞 API 負載的最常見原因——把正確的值用錯方向轉換。
- epoch 轉日期:貼上 1700000000 並讀取 UTC 或本地日期
- 日期轉 epoch:選擇 2026-01-01 00:00:00 UTC 得到 1767225600
- timestamp 轉 epoch:把類似日期的值正規化為 Unix 秒或毫秒
- Unix 時間轉 timestamp:通常是同一個值,但要確認目標期望秒還是毫秒
epoch 時間轉換器應理解的輸入
像 unix ts converter、unixtime converter、epochconverter 與 unix timestamp convertor 這樣的搜尋表達同一種需求:貼上時間戳並查看日期。真正改變答案的區別是單位與時區,因此可靠的轉換器應接受各種常見形式,並標明它辨識到的內容。
- 10 位 Unix 秒,如 1700000000
- 13 位 Unix 毫秒,如 1700000000000
- 來自某些資料庫與日誌的 16 位微秒
- 來自追蹤系統與 Go 的 19 位奈秒
- ISO 8601 字串,如 2026-01-01T00:00:00Z
- 本地時鐘日期與時間加上所選時區
複製轉換值之前要核對什麼
轉換器只能在輸入無歧義的限度內保持正確。在把時間戳複製到測試、cron、遷移或 API 請求之前,確認單位、時區與期望精度。最快的檢查是結果年份:接近 1970 年或非常遙遠的日期幾乎總是表示單位不匹配,而非轉換器出錯。
- 接收系統期望秒還是毫秒?
- 顯示的日期是 UTC 還是本地時間?
- 時間戳表示一個瞬間還是一個本地日曆日期?
- 資料庫欄位儲存的是原生 datetime、Unix 秒還是 Unix 毫秒?
- 結果是否接近 1970 年或非常遙遠?這通常表示單位不匹配
實例:一個瞬間,三種表示
取瞬間 2026-01-01 00:00:00 UTC。作為 Unix 秒是 1767225600;作為 Unix 毫秒是 1767225600000;作為 ISO 8601 是 2026-01-01T00:00:00Z。三者描述同一時刻——只有格式與單位不同。瞬間本身從不攜帶自己的時區;紐約會把同一個值顯示為 2025-12-31 19:00:00,因為偏移是在顯示時套用,而不儲存在數字裡。
epoch 轉換器常見問題
- 從 epoch 轉換器複製的最佳格式是什麼?
- 對程式碼,按目標 API 的文件複製 Unix 秒或毫秒。對人,複製帶 Z 或顯式時區偏移的 ISO 8601,使瞬間無歧義。
- epoch 轉換器和 Unix 時間轉換器一樣嗎?
- 對大多數開發者搜尋而言,是的。epoch 轉換器、Unix 時間轉換器、Unix 時間戳轉換器與 Unix 紀元計算機都在 Unix 紀元時間戳與可讀日期之間互轉。
- 為什麼 epoch 轉換器顯示不同的本地時間?
- 因為它們套用了不同的時區。底層的 UTC 瞬間相同,只是本地顯示不同。把轉換器切換到 UTC 即可比較規範值。
- 怎麼知道我的數字是秒還是毫秒?
- 數位數。現代 10 位的值是 Unix 秒,13 位的值是 Unix 毫秒。如果 10 位的值在 JavaScript 中落在 1970 年附近,代表被當作了毫秒,需要乘以 1000。