時間戳轉換

Unix 時間戳記與日期時間雙向互轉,自動辨識 10 位(秒)與 13 位(毫秒),可切換本機時區與 UTC。所有計算都在瀏覽器本機完成,不上傳任何資料。
目前的時間戳記(秒)
毫秒

時區
時間戳記

日期時間

說明:
1. 時間戳記欄按位數自動判斷單位:10 位當作秒,13 位當作毫秒,判斷結果會顯示出來,判錯了可以直接改。
2. 上方的時區開關同時作用於兩個方向:切到 UTC 後,「日期時間」框裡填的時間會被當作 UTC 時間解釋。
3. 支援 1970 年以前的負數時間戳記,也支援 16 位(微秒)與 19 位(奈秒)輸入。
4. 輸出的每一行都可以點擊複製。
5. 頁面頂部的目前時間戳記每秒重新整理,取的是你這台裝置的系統時鐘 —— 裝置時間不準,這裡就不準。

關於 Unix 時間戳記

時間戳記是什麼意思?

Unix 時間戳記是一個整數,表示從 1970 年 1 月 1 日 00:00:00 UTC 到某個時刻之間經過的秒數。它不帶時區、不帶格式,就是一個數 —— 這正是它的用處:全世界的機器對同一時刻都得到同一個數字,存進資料庫、塞進 API、跨系統傳遞都不會因為「台北時間還是東京時間」「年月日還是月日年」而產生歧義。要給人看的時候,再按當地時區渲染成日期。

所以時間戳記本身沒有時區。「把時間戳記轉成台北時間」這句話裡,轉換發生在顯示這一步,不在儲存那一步。本頁上方的時區開關改的也只是顯示與解釋方式,同一個時間戳記在兩種時區下是同一個時刻。

10 位和 13 位有什麼區別?

10 位是,13 位是毫秒,差一個 1000 倍。這是實際用起來最容易出錯的地方:Java 的 System.currentTimeMillis()、JavaScript 的 Date.now() 給的是毫秒(13 位),而 Unix date +%s、PHP 的 time()、MySQL 的 UNIX_TIMESTAMP() 給的是秒(10 位)。把毫秒當秒解釋,會得到西元 57000 多年;把秒當毫秒解釋,會得到 1970 年 1 月上旬。

判斷方法很簡單,看位數就夠了:目前這個年代的秒級時間戳記是 10 位,毫秒級是 13 位,短期內不會變。本頁會自動按位數判斷並把判斷結果顯示出來,如果你的資料確實不是這個單位,改一下輸入即可。偶爾還會遇到 16 位(微秒)和 19 位(奈秒),多見於 Go、Python 的高精度 API 和鏈路追蹤系統,本頁也能辨識。

為什麼起點是 1970 年?

這個起點叫 Epoch,來自 Unix 系統的早期實作。1970 年並沒有什麼特殊含義,只是當時訂標準的人挑了一個剛過去不久的整年,方便用當時的 32 位元整數表示前後幾十年。後來 Unix 傳播開,這個約定就被 C、Java、JavaScript、各種資料庫和幾乎所有網路協定繼承了下來。

32 位元有號整數能表示的最大秒數對應 2038 年 1 月 19 日,超過之後會溢位成負數 —— 這就是「2038 年問題」。現代系統基本都改用 64 位元儲存,不再有這個上限,但一些舊裝置、舊韌體和早年寫死了 32 位元欄位的協定仍然會中招。另一頭,負數時間戳記表示 1970 年以前的時刻,是合法的,本頁也支援。

各語言裡怎麼取時間戳記

命令列用 date +%s 取秒,date +%s%3N 取毫秒(Linux;macOS 的 date 不支援 %N,裝 coreutils 用 gdate)。JavaScript 是 Date.now()(毫秒)和 Math.floor(Date.now()/1000)(秒)。Python 是 time.time(),回傳浮點數秒。Java 是 System.currentTimeMillis()。PHP 是 time()

資料庫這邊:MySQL 用 UNIX_TIMESTAMP() 取,用 FROM_UNIXTIME(ts) 轉回日期(注意它按連線的時區渲染);PostgreSQL 用 EXTRACT(EPOCH FROM now())to_timestamp(ts)。這類問題搜的人不少,但要的是一行程式碼,不是一個網頁 —— 抄走即可。

常見問題

時間戳記轉換出來的時間不對,差了 8 小時?

八成是時區問題。台灣是 UTC+8,如果一個時間戳記按 UTC 渲染,看起來就會比台北時間早 8 小時。用頁面上方的時區開關切換一下,對得上就是這個原因。另外,資料庫函式(如 MySQL 的 FROM_UNIXTIME)按連線工作階段的時區渲染,伺服器時區沒設對時也會差這 8 小時。

怎麼判斷時間戳記是秒還是毫秒?

看位數:10 位是秒,13 位是毫秒。本頁會自動辨識並顯示判斷結果。轉出來是 1970 年 1 月上旬,說明把秒當成了毫秒;轉出來是幾萬年後,說明把毫秒當成了秒。

支援 1970 年以前的時間嗎?

支援。1970 年以前用負數時間戳記表示,例如 -86400 是 1969 年 12 月 31 日。直接貼進來即可,不需要額外設定。

目前的時間戳記準不準?

它取自你這台裝置的系統時鐘,和本站伺服器無關(本站的工具全部在瀏覽器本機執行)。裝置時間不準,這裡顯示的就不準。需要精確時間請先校準系統時鐘。

2038 年問題會影響這個頁面嗎?

不會。JavaScript 用雙精度浮點數儲存時間,可表示的範圍遠超 32 位元整數,本頁轉換 2038 年之後的時間戳記沒有問題。受影響的是那些仍然用 32 位元有號整數存時間的系統。

時間戳記和 ISO 8601 有什麼區別?

時間戳記是一個數字,ISO 8601 是一種文字格式(如 2026-08-17T12:00:00.000Z)。前者精簡、便於計算和比較,後者人能直接讀、自帶時區資訊。API 裡兩種都常見,本頁的輸出同時給出了這兩種形式。

資料會上傳嗎?

不會。轉換用的是瀏覽器內建的 Date 物件,純本機計算,沒有任何請求。頁面載入完之後斷開網路,這個工具照常可用。詳見隱私權政策

還有別的開發工具嗎?

有。JSON 格式化可以檢視 API 回應的資料結構,Base64 編解碼處理編碼問題,MD5SHA-256 用於計算摘要與驗證檔案。