若要將 Unix 時間戳轉換為 SQL 日期，首先確認儲存的數字是 epoch 秒數或毫秒數，然後將正確的單位傳入資料庫的 epoch 轉日期函式，並謹慎選擇顯示時區。Unix 時間戳會從 1970-01-01T00:00:00Z 開始計算時間。Unix time 本身以秒為單位定義；毫秒值則大了 1,000 倍。這項差異很重要，因為若將 13 位數的毫秒值解碼為秒數，產生的年份將不符合常理，而非預期時間點。不同 SQL 資料庫提供不同函式來執行相同操作，因此最安全的工作流程是先辨識來源與單位，使用 Unix Timestamp Converter 解碼一個值，並在撰寫或測試查詢時，將該人類可讀的結果作為檢核點。轉換器完全在你的瀏覽器中執行，並同時顯示 ISO 8601、UTC、裝置本地時間及相對標籤。它也能將日期轉換回 epoch 秒數與毫秒數。因此，在查詢前、除錯期間，或檢查 FROM_UNIXTIME()、to_timestamp()、DATEADD() 或其他資料庫運算式傳回的結果時，這項工具都很有用。特別是 UTC 輸出可提供穩定的參考基準，用來與 SQL 結果比較；本地時間則能協助你判斷工作階段的時區設定是否改變了顯示方式。
SQL 實際上轉換的內容
Unix 時間戳是從 Unix epoch 開始計算的整數，而不是格式化後的日曆欄位。它本身不包含獨立的時區資訊，因此這個數字會辨識一個時間點，而輸出層則決定該時間點如何呈現。Unix time 參考資料定義了日誌、API、資料庫及排程工作等系統所使用的 epoch 慣例。接著，SQL 引擎會套用各自的傳回型別與時區規則，因此不含時區的 datetime、包含時區的值，以及格式化字串，可能無法直接比較。
在執行任何轉換函式之前，先確立來源單位。Unix time 以秒為基準單位，而毫秒則是該值的 1,000 倍。目前的 epoch 秒數通常有 10 位數，epoch 毫秒數則通常有 13 位數。數字長度是實用的線索，但並非證據：較舊的記錄、合成測試資料或非標準 API 可能呈現不同外觀。結構描述、資料產生器或欄位名稱仍是更可靠的證據來源。
| 儲存表示法 | 比例 | SQL 處理方式 |
|---|---|---|
| Epoch 秒數 | Unix 基準單位 | 直接傳入以秒為單位的轉換函式。 |
| Epoch 毫秒數 | 1,000 × epoch 秒數 | 除以 1,000，或使用明確新增毫秒的運算式。 |
不要僅因為某個值來自名稱含有 Unix 的欄位，就假定它使用秒數。請先在結構描述或產生器文件中確認比例，然後將該單位記錄在查詢與儀表板旁。這項檢查可避免最嚴重的錯誤：將有效的數字以錯誤的比例解讀。
為 SQL 查詢解碼時間戳
將轉換器作為查詢前的檢核點。它會將一個原始值轉換成四種易讀的檢視，並在你的裝置本機執行計算，讓你在撰寫特定方言的 SQL 之前，先取得預期結果。
- 完全複製原始值。保留每個數字，並確認它來自資料庫欄位、API 酬載、日誌行或匯出檔案。
- 開啟 Timestamp → Date 欄位。將 Unix 值貼到轉換器中，不要加上前綴，也不要事先轉換成其他格式。
- 選取正確的單位。選擇 Seconds 或 Milliseconds。轉換器會依數字位數自動偵測，但當結構描述或產生器提供明確答案時，應覆寫該選擇。
- 閱讀全部四項結果。ISO 8601 與 UTC 不受時區影響。本地時間反映你的裝置時區，而 Relative 顯示與目前時間點的距離。
- 必要時進行反向檢查。在 Date → Timestamp 欄位輸入類似 2023-11-14T22:13:20Z 的日期，以取得對應的 epoch 值（以秒數及毫秒數表示）。
使用 ISO 8601 或 UTC 結果作為 SQL 比較目標，因為它們不依賴你的裝置時區。調查自己時區中的事件時，請使用 Local time；需要快速判斷事件年代時，請使用 Relative。Date → Timestamp 面板也接受單純的 UTC 日期或自然語言日期，因此可用於檢查以多種格式傳入的值。往返測試也很簡單：取得已知日期的時間戳、將其解碼、把日期轉回去，並確認傳回相同的 epoch 值。
在資料庫中執行原生轉換
一旦預期 UTC 值已知，請選取你的資料庫支援的運算式。在以下範例中，epoch_seconds 代表包含 epoch 秒數的欄位或綁定值。
- 讓函式符合資料庫引擎。MySQL、PostgreSQL、SQL Server 與 SQLite 並不共用一個可攜式的 epoch 轉日期函式。
- 代入來源欄位或參數。讓單位在欄位名稱、查詢參數或鄰近文件中清楚可見。
- 決定結果的顯示方式。UTC 是用於比較的最穩定值，而工作階段或用戶端時區可能產生不同的本地表示法。
- 將資料庫結果與轉換器的 UTC 輸出比較。若兩者不一致，請先檢查單位，再變更時區設定。
| 資料庫 | epoch 秒數的運算式 | 要驗證的結果 |
|---|---|---|
| MySQL | FROM_UNIXTIME(epoch_seconds) | 傳回日期／時間值，其呈現方式會受到工作階段時區影響。 |
| PostgreSQL | to_timestamp(epoch_seconds) | 傳回包含時區的時間戳；其顯示方式由工作階段時區控制。 |
| SQL Server | DATEADD(second, epoch_seconds, CAST('1970-01-01T00:00:00+00:00' AS datetimeoffset(7))) | 將秒數位移加至具 UTC 感知能力的起點。請將此值與 DATEADD 可接受的位移範圍核對。 |
| SQLite | datetime(epoch_seconds, 'unixepoch') | 因為使用 'unixepoch' 修改項，所以會產生 UTC 日期／時間文字。 |
SQL Server 運算式以明確的 UTC 位移開頭，而 SQLite 的 'unixepoch' 修改項則直接要求 UTC 輸出。MySQL 與 PostgreSQL 可以在工作階段時區中呈現相同的時間點，因此正確的時間點在用戶端仍可能看起來不同。如需瀏覽更多資料庫引擎的逐函式參考資料，請參閱如何在 SQL 查詢中轉換 Unix 時間戳。
將毫秒值轉換為 SQL 日期
毫秒欄位不得直接傳入預期使用秒數的函式。請依應用程式所需的精確度加以正規化：
- MySQL： FROM_UNIXTIME(epoch_ms / 1000)
- PostgreSQL： to_timestamp(epoch_ms::double precision / 1000.0)
- SQL Server： DATEADD(millisecond, epoch_ms % 1000, DATEADD(second, epoch_ms / 1000, CAST('1970-01-01T00:00:00+00:00' AS datetimeoffset(7))))。這會保留毫秒餘數，但仍受該函式位移範圍限制。
- SQLite： strftime('%Y-%m-%dT%H:%M:%fZ', epoch_ms / 1000.0, 'unixepoch')
在 PostgreSQL 與 SQLite 中使用 1000.0 可避免僅執行整數除法。SQL Server 形式會將完整秒數與剩餘毫秒分開。若轉換時捨棄餘數，即使顯示的秒數正確，也可能與高精確度的 ISO 8601 值不一致。
判定故障前先比對時區
每次比較都應從 UTC 開始。轉換器的 UTC 與 ISO 8601 檢視不會隨裝置時區改變，因此可作為測試的穩定預期值。Local time 檢視會遵循讀取者裝置上設定的時區，因此適合用於個人情境，但並非通用的測試固定值。
請比較相同的時間點，而不是日期的寫法。如果日曆日期與時鐘時間不同，先測試秒數與毫秒數的選項。如果時間點正確但顯示方式不同，請檢查資料庫工作階段或用戶端時區。如果數值接近但不完全相同，請檢查四捨五入、截斷，以及來源是否保留小數秒。Relative 結果是快速的年代檢查方式，不是能與 SQL 運算式直接比較的欄位。
疑難排解：單位、時區、精確度與範圍
大多數轉換意外都源自單位比例、時區呈現、精確度或儲存範圍。轉換器會讓前三項清楚可見；第四項則取決於資料庫結構描述及所使用的函式。
錯誤的單位
將毫秒值當成秒數會導致比例錯誤，並可能產生遙遠未來的日期。當查詢仍傳回看似有效的時間戳時，這種錯誤特別容易遭忽略。請確認產生器的單位、檢查轉換器所選的 Seconds 或 Milliseconds 控制項，並在執行查詢前將數值正規化。
時區呈現
Unix 時間戳在各地都會辨識相同的時間點，但 SQL 函式可能傳回依目前工作階段或用戶端時區格式化的值。變更查詢之前，請先在 UTC 中比較時間點。如果 UTC 與轉換器的結果一致，表示底層轉換是正確的，只需要調整呈現方式。
次秒精確度
資料庫函式、用戶端驅動程式或顯示格式可能將毫秒值四捨五入或截斷。請將 ISO 8601 的小數部分與原始欄位及 SQL 結果比較。如果只有小數部分不同，請保留來源精確度，或選擇能顯示小數部分的格式。
2038 年界限
以帶正負號的 32 位整數儲存 Unix time 的系統，會在 19 January 2038 的 03:14:07 UTC 發生溢位，並回繞至 1901。64 位元儲存型別不受此整數上限影響，而現代瀏覽器使用 64 位元雙精度浮點數，因此轉換器能處理遠超 2038 年的日期。舊式嵌入式系統與資料庫程式仍可能含有這項缺陷。這是範圍問題，而非秒數與毫秒數的問題，儘管個別 SQL 函式可能會施加自身的引數限制。
讓驗證工作流程可重複執行
可靠的做法很簡短：找出數字的來源、判斷其單位、在 Unix Timestamp Converter 中解碼、執行相符的資料庫運算式，並與轉換器的 UTC 結果比對。如果結果不一致，請一次只變更一個變數——先單位，接著時區，再來精確度——而不要盲目編輯查詢。
工具中的每次轉換都是使用平台的 Date 物件與明確的 UTC 格式，在你的瀏覽器中運算。貼上的值不會上傳，因此相同的工作流程可用於正式環境的日誌項目、API 承載內容與本機開發資料。當 SQL 結果與轉換器一致時，請在結構描述中記錄原始欄位的單位。像 epoch_ms 這樣清楚的名稱，或標準化為 epoch 秒數，都能消除下一位開發人員的疑惑。