一個 Unix 時間戳轉換器 是開發人員或數據分析師經常需要使用的簡單但不可或缺的工具。這是一個方便的工具，可以將一個長且看似隨機的數字轉換為我們能夠理解的日期和時間。當你在檢查系統日誌、使用 API 或查詢以這種超高效格式存儲時間的數據庫時，這種轉換至關重要。

什麼是 Unix 時間戳，為什麼它重要

在你真正欣賞一個好的轉換器之前，你必須了解那個數字實際上 是什麼。從本質上講，Unix 時間戳只是一個運行的秒數計數。它跟踪自 1970 年 1 月 1 日 00:00:00 UTC 以來所經過的總秒數。這一特定的時刻被稱為「Unix 紀元」。

那麼為什麼選擇這種方法？簡單和高效。將時間存儲為單一整數比像「2021 年 1 月 1 日星期五 12:00:00 AM GMT」這樣冗長的字符串要緊湊和高效得多。這使得它在幾個關鍵領域中非常完美：

• 數據庫存儲：時間戳很小，使其快速索引和查詢。這對性能來說是一個巨大的優勢。
• API 負載：來回發送一個數字比發送完整的日期字符串要輕得多，從而導致更快的響應時間。
• 日誌文件：當你在解析來自數十個不同系統的日誌時，擁有一個統一的、與語言無關的時間戳是救命稻草。
• 計算：需要知道一個過程花了多長時間？只需將結束時間戳減去開始時間戳。這是簡單的整數運算。

秒、毫秒及更高精度

經典的 Unix 時間戳是一個 10 位數 的數字，表示秒數。但隨著技術的發展，對更精細的時間記錄的需求也在增加。這就是你開始看到不同長度的時間戳的地方，這是一個常見的障礙。

這裡是你在實際應用中通常會遇到的快速概述。將一種誤認為另一種是經典的「錯誤千位數」錯誤，可能會導致一些非常混淆的錯誤。

常見的 Unix 時間戳格式一覽

單位	位數	典型用例	示例值（同一時刻）
秒	10	大多數後端系統、數據庫和 API 的標準。	1609459200
毫秒	13	在網絡技術中非常常見，特別是 JavaScript。	1609459200000
微秒	16	用於高頻交易或科學計算。	1609459200000000

搞清楚這些格式是關鍵。如果一個工具期望的是秒而你提供的是毫秒，你將得到一個未來幾千年的日期。這是我們每個人都曾犯過的錯誤！

著名的 2038 年問題

Unix 時間戳的優雅簡單性也創造了一個定時炸彈：「2038 年問題」。在舊的 32 位 系統上，時間戳被存儲為有符號的 32 位整數。問題在於，這種類型的整數有一個上限——它無法保存大於 2,147,483,647 的數字。

在 2038 年 1 月 19 日 03:14:07 UTC，自紀元以來的秒數將超過該限制。當它發生時，整數將「回繞」，變成一個負數。這將導致脆弱的系統將日期解釋為回到 1901 年，這可能會使數十億仍在使用的舊設備崩潰。你可以從 StrongDM 的專家那裡獲得更多有關 Unix 紀元及其影響的見解。

幸運的是，這不是我們大多數人日常需要擔心的事情。絕大多數現代系統已經轉向使用 64 位 整數進行時間記錄。64 位整數是如此龐大，以至於在未來 2920 億年 內不會溢出，從而有效地解決了這個問題。

不過，這是一段精彩的計算歷史，也是如果你在舊的嵌入式系統或舊代碼庫上工作時需要掌握的重要知識。理解這些基本原則使得任何 Unix 時間戳轉換器在你手中成為一個更強大的工具。

在瀏覽器中輕鬆進行轉換

雖然使用終端命令或代碼片段可以完成工作，但這並不總是最快的辦法。有時候，你只需要立即得到答案，而不必打斷你的專注或切換窗口。這就是一個好的基於瀏覽器的工具真正展現其價值的地方，特別是一個專門的 Unix 時間戳轉換器，它就在你的瀏覽器中。

這裡的真正魔力在於保持流暢。想像一下：你正在瀏覽瀏覽器的開發者工具中的 API 響應，並發現一個時間戳。

不必再開啟另一個標籤頁或啟動終端機，您只需按下快速的鍵盤快捷鍵，粘貼數字，即可立即獲得答案。這就是使用像 ShiftShift Extensions 這樣的工具所帶來的無縫工作流程，它將一堆實用工具整合到一個命令面板中。

使用鍵盤快捷鍵獲得即時答案

一切都歸結於速度。使用 ShiftShift 這樣的工具，快速雙擊 Shift 鍵（或在 Mac 上按 Cmd+Shift+P）即可打開命令欄。只需開始輸入 "timestamp"，轉換器就會出現。粘貼您的值，您就能立即獲得可讀的日期。

這就是它的樣子——命令面板已準備好在您當前的頁面上轉換時間戳。

最棒的是它如何無縫集成而不會妨礙您的工作。轉換器只是同一疊加層中眾多工具之一，因此您無需離開正在做的事情。

這種方法對於開發人員、測試人員以及幾乎整天都在瀏覽器中工作的人來說都是救星。此外，轉換完全在您的機器上進行。來自日誌或 API 響應的敏感數據永遠不會離開您的計算機，這對於隱私來說是一個巨大的勝利。

能夠在同一介面中轉換時間戳、重新格式化混亂的 JSON 數據，然後計算時間差——這是一個巨大的時間節省。它將繁瑣的多工具過程轉變為單一、流暢的操作。

不僅僅是單一工具

一個優秀的瀏覽器內工具通常不僅僅是一個單一工具；它是整個工具包的一部分。您經常會發現自己在使用時間戳轉換器的同時還在使用其他功能。

例如，您可能會將其與以下功能配對：

• JSON 或 SQL 格式化工具，在提取時間戳之前清理一些代碼。
• 內建計算器，用於對 epoch 值進行快速計算。（您可以在 ShiftShift 計算器頁面上玩一個類似的工具，看看它是如何工作的）。
• 文本比較工具，用於找出兩個 API 響應之間的差異，包括時間戳。

將所有這些基本工具集中在一個地方，能夠創造出更快、更連貫的工作流程。這不僅僅是關於便利性——而是關於消除那些小而重複的干擾，這些干擾累積起來會在一天內消耗您的生產力。

代碼中的實用時間戳轉換

如果您是開發人員，您知道處理時間戳只是工作的一部分。但說實話，語法在不同語言之間從來都不完全相同。本節是您的速查表，包含了您可以立即抓取並使用的代碼片段，適用於您實際工作的平臺。再也不需要翻找舊的 Stack Overflow 討論串——這裡有實用的範例讓您快速上手。

無論您是在網頁前端處理數據、編寫 Python 腳本，還是查詢數據庫，轉換 epoch 時間都是一項基本技能。我們將逐步介紹最常見的場景，從將 epoch 整數轉換為可讀字符串，然後再反向操作。

在 JavaScript 中轉換時間戳

JavaScript 的 Date 對象是您在這裡的主要工具，但它有一個主要的特點，經常讓開發人員困惑：它以 毫秒 為單位，而不是秒。這在您的前端與使用標準 10 位、基於秒的時間戳的後端通信時，經常會成為錯誤的來源。

要正確將標準 Unix 時間戳（以秒為單位）轉換為 Date 對象，您必須將其乘以 1000。

// 一個標準的 10 位 Unix 時間戳（以秒為單位）
const unixTimestamp = 1672531200;

// 轉換為毫秒，然後創建 Date 對象
const dateObject = new Date(unixTimestamp * 1000);

// 格式化為可讀的 UTC 字符串
// 輸出：Sun, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

需要當前時間戳？ Date.now() 會以毫秒的形式提供給您。只需記得在將標準的 10 位時間戳發送回 API 之前，除以 1000 並向下取整。

使用 Python 處理轉換

在後端，Python 的 datetime 模塊是一個強大的工具。它非常靈活，並且對時區感知的轉換有出色的支持，使其成為需要在不同區域精確處理時間的服務的可靠選擇。

這是使用 datetime 庫轉換時間戳的簡單方法：

import datetime

一個標準的 10 位 Unix 時間戳

unix_timestamp = 1672531200

將時間戳轉換為 datetime 對象

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

格式化為乾淨、可讀的字符串

輸出：2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
這種簡單的方法為您在 Python 應用中管理 epoch 時間提供了一種乾淨且可靠的方式。如果您正在處理包含時間戳的複雜數據結構（如 JSON），您可能會發現我們關於使用 JSON 格式化工具 的指南對於調試很有幫助。

使用 SQL 進行數據庫轉換

數據庫通常將時間存儲為 Unix 時間戳，因為它們效率高。好消息是，大多數 SQL 方言都有內建函數，可以在查詢中直接處理這些轉換。

這比從原始整數時間戳提取並在應用程式代碼中轉換它們要高效得多。

Unix 時間戳幾乎是通用的，使用於超過 90% 的程式語言——從 JavaScript 的 Date.now() 到 Python 的 time.time()——驅動著數兆次的日常操作。正確處理時區至關重要；一個穩健的 unix 時間戳轉換器 可以處理超過 400 個 IANA 時區，這有助於防止在估計的 62% 的全球應用程式中出現不明確的時區錯誤。您可以在 Fossa 找到有關這些工具全球採用的更多詳細資訊。

對於開發人員來說，能夠格式化 SQL、轉換時間戳並計算紀元差異而無需離開您的機器是一個巨大的生產力提升。這種以本地為先的方法還使您遵守現代數據隱私標準，如 GDPR 和 CCPA。

MySQL 範例

在 MySQL 中，您最常使用的函數是 FROM_UNIXTIME()。它接受一個紀元整數並將其整齊地轉換為標準 DATETIME 格式。

SELECT FROM_UNIXTIME(1672531200);
-- 返回: '2023-01-01 00:00:00'
要反向操作——從日期字符串回到紀元時間戳——只需使用 UNIX_TIMESTAMP()。

SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00');
-- 返回: 1672531200

PostgreSQL 範例

PostgreSQL 使用一個稍微不同但同樣強大的函數：to_timestamp()。這個函數直接將 Unix 時間戳轉換為 TIMESTAMP WITH TIME ZONE 值。

SELECT to_timestamp(1672531200);
-- 返回: 2023-01-01 00:00:00+00
因為它一開始就能識別時區，所以對於服務全球受眾的應用程式來說，這是一個非常穩健的選擇，時間精確性是不可妥協的。

在終端中掌握時間戳轉換

如果您習慣使用命令行，切換到瀏覽器或 GUI 進行快速的時間戳轉換會真正影響工作流程。這會打斷您的專注。好消息是您不必這樣做；Linux 和 macOS 都有強大且原生的工具，可以在不離開終端的情況下處理這些轉換。

這方面的首選工具是樸素的 date 命令。它幾乎在每個類 Unix 系統上都有，但有一個問題：在 Linux (GNU) 和 macOS (BSD) 中，作為 unix 時間戳轉換器 使用的語法是不同的。了解這一點是每次正確使用的關鍵。

在 Linux 上轉換時間戳

在 Linux 上，語法簡潔且易於記憶。您只需使用 -d 標誌來指定日期，但必須告訴它您提供的是紀元時間戳，方法是用 @ 符號作為前綴。

假設您正在查看日誌並發現時間戳 1704067200。要查看這實際上意味著什麼，您可以運行：

date -d @1704067200

瞬間，您將獲得一個人類可讀的日期，類似於 Mon Jan 1 00:00:00 UTC 2024。您還可以使用自定義格式來清理該輸出。

date -d @1704067200 +"%Y-%m-%d %H:%M:%S"

輸出: 2024-01-01 00:00:00

專業提示：當您開始將其他命令通過管道傳遞給它時，這個命令會變得非常強大。您可以從一個龐大的日誌文件中 grep 一個時間戳，並將其直接傳遞給 date 以進行即時轉換。這將多步調試任務轉變為一個簡單而優雅的一行命令。

在 macOS 上處理轉換

現在，如果您在 Mac 上運行相同的 Linux 命令，它會拋出錯誤。macOS 使用的 BSD 版本的 date 需要 -r 標誌，而不需要 @ 前綴。

這是您在 Mac 上轉換相同時間戳的方式：

date -r 1704067200

與 Linux 版本一樣，您可以添加格式選項以獲得所需的確切輸出。

date -r 1704067200 +"%Y-%m-%d %T %Z"

輸出: 2024-01-01 00:00:00 UTC

這一小差異對於經常在 Linux 和 macOS 之間切換的人來說是一個經典的絆腳石。記住這兩個版本將為您節省大量的麻煩。

一旦您掌握了這些命令，您可以將時間戳轉換直接融入您的 shell 腳本和日誌分析中。這是一項小技能，但能帶來相當大的生產力提升，讓您保持專注於重要的工作。

常見的時間戳陷阱及其避免方法

處理 Unix 時間戳表面上看似簡單，但幾個經典錯誤可能導致一些真正令人抓狂的錯誤。這些問題有一個不好的習慣，會在錯誤實際發生的地方很遠的地方出現，讓調試變得非常麻煩。將本節視為您識別和避免我多年來看到的最常見時間戳陷阱的實地指南。

秒與毫秒的混淆

最常見的錯誤無疑是將秒與毫秒混淆。標準的 Unix 時間戳是一個 10 位數 整數，表示自紀元以來的秒數。但許多系統，特別是在 JavaScript 世界中，使用的是 13 位數 的毫秒時間戳。

當前端應用程式將毫秒值傳遞給預期為秒的後端時，事情就會變得混亂。

對於一個 unix timestamp convertor 而言，那個 13 位數字看起來像是數千年後的日期。這可能會悄無聲息地破壞數據驗證、排程邏輯以及你試圖保留的任何歷史記錄。這是一種微妙的數據損壞，你甚至可能幾週都不會注意到。

時區陷阱

另一個即使是資深開發者也會陷入的陷阱是時區處理。根據其定義，Unix 時間戳始終是協調世界時間（UTC）。它代表一個單一的、普遍的時間點，完全不受位置影響。當你忘記這一點並假設時間戳反映用戶的當地時間時，陷阱就會啟動。

這個錯誤通常發生在你將時間戳轉換為可讀日期時，卻沒有指定時區。你的系統通常默認為伺服器的當地時間，導致混亂。紐約的用戶可能會看到一個為倫敦的某人設計的時間，但卻偏差了幾個小時。

黃金法則很簡單：在你的後端中始終將時間戳視為 UTC。以 UTC 存儲它們，以 UTC 處理它們，並且僅在前端顯示時轉換為用戶的當地時間。

排除常見的時間戳轉換錯誤

當事情出錯時，症狀可能會令人困惑。這裡有一個我根據經驗整理的快速參考表，以幫助你快速診斷和修復最常見的問題。

症狀	可能原因	解決方案
日期在52361年或其他遙遠的未來。	毫秒與秒。 你正在將一個 13 位數的毫秒時間戳傳遞給一個預期為 10 位數的秒時間戳的函數。	在處理之前將時間戳除以 1000。始終驗證進來的時間戳的位數。
時間偏差幾個小時，但日期正確。	時區處理不當。 時間戳是使用伺服器的當地時間而不是用戶的或 UTC 轉換的。	確保所有轉換明確指定目標時區。僅在客戶端轉換為當地時間。
日期停留在1970年1月1日。	無效或空的時間戳。 時間戳值可能是 0、null 或 undefined。	在嘗試轉換之前添加檢查以確保時間戳是有效的正整數。提供一個後備值。
出現 "無效日期" 或 NaN 錯誤。	錯誤的數據類型。 當需要數字時，時間戳被視為字符串或其他非數字類型。	在使用日期函數之前，明確將時間戳解析為整數（在 JS 中使用 parseInt()，在 Python 中使用 int()）。

記住，對輸入進行快速檢查可以為你節省數小時的調試時間。

使用標準格式避免歧義

在系統之間傳遞數據時依賴原始整數時間戳可能會導致混淆。因此，標準化為像 ISO 8601 (2022-05-17T12:00:00Z) 這樣的通用字符串格式是一個很好的防禦措施。將 Unix 時間戳（例如 1652905200）轉換為這樣清晰、自我文檔化的格式有助於防止在估計的 37% 的跨時區 API 調用中出錯。

考慮到 72% 的《財富》500 強公司在日誌分析中使用 Unix 時間戳，其中一次失誤可能會導致每小時超過 $10,000 的停機成本，精確性至關重要。你可以在 EpochConverter 上閱讀更多有關不同行業如何使用紀元時間的信息。

對於管理數據庫的人來說，一致的時間戳處理同樣至關重要。如果你發現自己經常在數據庫中與不同的時間戳格式作鬥爭，我們的指南可以幫助你使用強大的 SQL 格式化工具 來保持查詢的整潔和可預測性。

這個決策樹幫助你選擇適合你操作系統的正確命令，防止在需要快速轉換時出現語法錯誤。

上面的流程圖清楚地顯示了 Linux 中 date 命令（-d @...）和 macOS（-r ...）之間的關鍵語法差異——這是開發者在不同環境中工作時常見的絆腳石。

為了加固你的代碼，始終實施檢查以驗證進來的時間戳的長度。一個簡單的函數檢查 10 位數（秒）或 13 位數（毫秒）值可以在這些錯誤損害你的應用邏輯之前捕捉到它們。

有關 Unix 時間戳的常見問題

一旦你掌握了 Unix 時間戳，幾個實用的問題幾乎總是會出現。我見過這些問題讓各級開發者困惑，因此讓我們澄清你在日常工作中會遇到的最常見問題。

為什麼這麼多 API 使用時間戳而不是 ISO 8601 字符串？

這實際上歸結為原始效率。Unix 時間戳只是一個單一的數字，與像 '2023-10-27T10:00:00Z' 這樣的字符串相比，它極其緊湊。

較小的大小意味著需要傳輸的數據更少，這樣可以節省帶寬並加快 API 的響應速度。

它們也完全不依賴於語言。沒有歧義，沒有解析的怪癖，也不必擔心區域格式。對於機器來說，處理數字總是比解析字符串更快，因此任何日期計算——例如計算兩個事件之間的時間——在計算上都更便宜。對於高性能系統來說，這種簡單性是一個巨大的優勢。

處理時區的正確方法是什麼？

這是最重要的一點。這裡有一條黃金法則：Unix 時戳始終是 UTC。它本身並不包含任何時區的概念。它只是從紀元開始的原始秒數計數。

時區只有在你需要將該時戳顯示給人類時才重要。

我的建議是？在後端的所有內容中都堅持使用 UTC。將其作為 UTC 時戳存儲在數據庫中，通過 API 傳遞時使用 UTC，並在伺服器端邏輯中全部使用 UTC。唯一應該將其轉換為本地時區的時候是在前端，顯示給用戶之前。這一單一做法將使你免於整個時區和夏令時間錯誤的宇宙。

我還需要擔心 2038 年問題嗎？

對於大多數新項目來說，可能不需要。"2038 年問題" 是舊系統的遺留問題，這些系統使用32 位有符號整數來存儲時戳。一旦該數字變得太大，它會回繞並變為負數，將日期回送到 1901 年。

值得慶幸的是，幾乎所有現代系統——從操作系統到數據庫——早已轉向64 位整數。這有效地將問題推遲到了遙遠的未來（實際上是數十億年），因此對我們來說不再是實際的擔憂。

話雖如此，如果你正在維護一個遺留系統或處理嵌入式硬件（例如物聯網設備），那麼這確實是需要注意的事情。始終了解你正在構建的架構類型。

我該如何快速在 Excel 或 Google Sheets 中轉換時間戳？

你不需要將數據提取到單獨的 Unix 時戳轉換器中。簡單的公式就能解決問題。假設你的時間戳在單元格 A1 中：

• 對於以秒為單位的時間戳（10 位數）： =A1 / 86400 + DATE(1970,1,1)
• 對於以毫秒為單位的時間戳（13 位數）： =A1 / 86400000 + DATE(1970,1,1)

只需將該公式輸入，然後將單元格格式設置為 "日期" 或 "日期時間"。這在快速分析數據導出時是個救星，讓你不必打斷工作流程。

---

厭倦了在編輯器、命令行和十幾個瀏覽器標籤之間不斷切換以完成簡單任務嗎？ShiftShift Extensions 套件將強大的 Unix 時戳轉換器、JSON 格式化工具、SQL 美化器等直接整合到你的瀏覽器中。你所需的一切只需一個鍵盤快捷鍵即可獲得。

立即在 https://shiftshift.app 獲取 ShiftShift Extensions，簡化你的工作流程