「這筆日誌，究竟是什麼時候發生的？」

在系統開發過程中，看到主控台輸出如 1736823600 般的數字。
雖然心裡明白「啊，這是 UNIX 時間」，但若要說出它具體代表哪個月、哪一天、幾點幾分，幾乎沒有人能立刻回答。

UNIX 時間與時區基礎知識：工程師必備的核心概念

日誌調查、資料庫確認、API 除錯……工程師的日常，便是一場與「對電腦很友善，但人類難以閱讀的數字」之間的戰鬥。

UNIX 時間：連結世界的「秒數」

UNIX 時間 (Epoch time) 是從 1970 年 1 月 1 日 00:00:00 UTC 起累積的秒數。

究竟為什麼要使用這麼難以閱讀的表示法呢？
這是為了讓散佈在全球各地的電腦，能正確共享「這一瞬間」。
「東京的上午 9 點」就是「倫敦的凌晨 0 時」，但在 UNIX 時間中，全球各地都是同一個數值。正因為有這份簡潔性，我們才能與地球另一端的伺服器同步交換資料。

開發現場最常見的「三大陷阱」

即便理解原理，我們仍會不經意地犯下「粗心」的錯誤。

1. 「秒」與「毫秒」的混淆

JavaScript 的 Date.now() 是 13 位數（毫秒），而 PHP 或 Python 的標準則是 10 位數（秒）。
「呼叫 API 後，日期居然變成 1970 年！」通常就是因為沒注意到位元數的差異。

2. 時區的隔閡

UNIX 時間本身始終是以 UTC (協定世界時) 為基準，但我們的生活是以 JST (日本標準時) 或本地時間為準。
有時忘了考慮這「9 小時的時差」，導致本應在深夜執行的批次處理卻在正中午狂跑……您是否曾遇過這樣的失敗？

3. 「2038 年」問題

以前總覺得是很遙遠的未來，但它正一點一滴地逼近。若有機會接觸舊系統，具備「這個變數在 2038 年會溢位嗎？」的視角，或許能拯救未來的您（或是您的接班人）。

身邊備妥「翻譯機」

別勉強用大腦進行複雜的運算或轉換，把工作交給工具吧。

本站的 UNIX 時間轉換工具 只要貼上數值，即可自動判別它是「秒」還是「毫秒」，並瞬間轉換成 UTC 與本地時間。

無論是在確認 API 規格，還是在故障排除的當下。
在忙碌的時刻，請將此工具作為您的「解讀時間之鏡」來靈活運用。

若您需要的是把 UTC 換算成日本時間（或反向），UTC⇄JST 換算參考手冊 整理了時差對照表、與台灣時間相差 1 小時的關係，以及 JavaScript、MySQL 與 CI 的 cron 會悄悄讓時間位移的地方。

結語

習慣之後，UNIX 時間其實是個非常公平且合理的機制。
若能自在地操縱數字背後的「時間」，作為工程師的視野將會變得更開闊、更清晰。來吧，讓時間成為您的盟友，享受更有趣的開發體驗！

常見問題

Unix 時間是 UTC 嗎？

是。Unix 時間是從 1970 年 1 月 1 日 00:00:00 UTC 起算的秒數，本身不帶時區概念。同一個瞬間，不論在台北還是紐約看，數值完全相同。時區只在轉換成人類可讀的日期時間時才會介入。

JavaScript 的時間戳是秒嗎？

不是。Date.now() 回傳的是毫秒，是一般 Unix 時間的 1000 倍。若把伺服器回傳的秒數直接丟進 new Date()，會得到 1970 年代的日期；反過來把毫秒當成秒，則會跑到很遠的未來。可以用位數分辨：以目前時間來說，秒是 10 位數，毫秒是 13 位數。

為什麼會變成 1970 年的日期？

多半是秒與毫秒搞混了。把秒數當成毫秒解讀時，幾乎不會離開起算點，因此落在 1970 年附近。另外也常見值為 null 或空字串時被轉成 0，剛好變成 1970-01-01。想確認是哪一種，可以把數值貼進 Unix 時間轉換 查看。