Unix 時間戳轉換器:紀元、時區和年份 57123 Bug

我的一款 Laravel SaaS 應用程式的用戶曾經透過電子郵件表示他的訂閱續訂日期看起來和報價;有點慷慨。&報價;帳單頁面告訴他,他的計劃將於今年 4 月 25 日更新 57123.

這個錯誤花了我尷尬的時間才找到,因為每個單獨的片段都是正確的。 React 前端已發送 Date.now()- 哪個回來了 毫秒- PHP 後端做到了 date('Y-m-d', $timestamp),這是期望 秒. 飼料 1740470400000 進入期待的函數 1740470400 而你將在大約 55,000 年後登陸。沒有例外,沒有警告,沒有失敗的測試。只有一位顧客禮貌地詢問他的訂閱是否真的持續到文明的熱寂。

時間戳看起來像是軟體中最無聊的話題。他們'實際上是我們擁有的最可靠的錯誤工廠之一:秒與毫秒、UTC 與局部、DST 轉換、2038 年翻轉。這 時間戳轉換器 在 toolz。dev 上存在是因為我厭倦了這樣做 new Date(x * 1000) 在瀏覽器控制台中每天四十次。本指南涵蓋了我現在檢查的內容,並按照檢查的順序進行。

TL;DR: Unix 時間戳記自 1970-01-01T00:00:00 UTC 起計算秒數。 10 位 = 秒,13 位 = 毫秒- 將它們混合起來會讓您的日期偏離 55,000 年。儲存 UTC,僅轉換用於顯示,使用 IANA 區域名稱,例如 Asia/Dhaka 而不是縮寫。將任何時間戳記貼到 時間戳轉換器 要取得 ISO 8601、RFC 2822、本機和 UTC 表單 - 它運行客戶端,因此時間戳記不在 JWT 生產日誌永遠不會離開您的瀏覽器。

什麼是 Unix 時間戳記?

Unix 時間戳記(紀元時間、POSIX 時間)是自此之後經過的秒數 1970 年 1 月 1 日,世界標準時間 00:00:00- "Unix epoch。"它'是一個整數,它沒有時區(它'根據定義總是UTC),並且實際上每個作業系統、語言和資料庫都理解它。最後一個屬性是它存活了五十年的原因:它是無人爭論的一次性格式。

為什麼是1970年?沒有深層的原因 - 這是一個方便的輪日期,接近貝爾實驗室建造 Unix 的時間,早期的 Unix 以 32 位元整數計算時間。任意選擇僵化為通用標準,這是非常 Unix 的。

一些值得在視覺上識別的參考點:

第四行是我最喜歡的例子,原因很微妙:有很多教學頁面清單 1740470400 作為&報價; 2025 年 2 月 25 日,12:00:00。&報價;實際上它's 世界標準時間 08:00- 有人在當地時區轉換過一次,從那時起錯誤的值就被複製貼上。使用工具而不是部落格文章驗證時間戳記。包括這個。

秒或毫秒 - 你怎麼說?

計算數字。對於當前時代的任何日期:

• 10 位數字 (1740470400) - 秒。 Unix 約定、大多數 API、PHP 和#39;s time()Python's time.time() (作為浮動),stripe's API。
• 13 位數字 (1740470400000) - 毫秒。 JavaScript's Date.now(),java's System.currentTimeMillis(),mongodb 日期。

這就是我的年份 57123 續訂日期的確切區別,因此 I'將闡明故障模式:

• ms 解釋為秒 → 日期約 55,000 年 未來
• 秒解釋為 ms → 日期 in 1970 年 1 月 (一切都崩潰到紀元後約三週內)

如果您看到簽名 - 古老的日期或荒謬的遙遠未來日期 - 您在閱讀一行程式碼之前就知道該錯誤。這 時間戳轉換器 偵測數字計數並標記兩種解釋,從而解決 " 這是 s 還是 ms?"兩秒鐘內爭論。

您實際上需要知道哪些日期格式?

三幾乎涵蓋了工作開發人員觸及的所有內容。

ISO 8601- 國際標準,以及您應該在 API 和日誌中排放的內容:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

沒有人提到的殺手級功能:ISO 8601 字串 按時間順序依字典順序排序. sort 在日誌檔案上就可以了。 02/25/2026-樣式格式可以'這樣做 - 更糟的是,美國 MM/DD 還有歐洲的 DD/MM 每個月有十二天無法區分。

RFC 3339 (規格) - ISO 8601 的網際網路協定設定檔。稍微嚴格一點;如果您的 API 發出 2026-07-13T09:30:45Z 你滿足兩者。這是標準化的格式。

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - 電子郵件和 HTTP 標頭、RSS 來源。你閱讀它的次數比寫它的次數多。

資料庫格式是近親:MySQL DATETIME 是 2026-07-13 09:30:45 (帶空格的 ISO),PostgreSQL timestamptz 渲染 2026-07-13 09:30:45+00.

我使用的語言如何處理時間戳記?

這三個來自我自己的堆疊 - 以及每個堆疊中的怪癖都讓我個人花費了時間。

JavaScript (女士一號):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

怪癖:一切都是毫秒,並且 new Date(1740470400) 默默地給你 1970 年 1 月 21 日而不是 2025 年 2 月。沒有錯誤。這種不對稱性是 Web 開發中最常見的時間戳錯誤。

PHP (秒一):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

怪癖: date() 格式在 伺服器's 預設時區,因此相同的程式碼會在您的機器上和生產中列印不同的日期。另外, new DateTime('@1740470400') 忽略您傳遞給建構函數的任何時區 - @ 形式始終為 UTC;你必須打電話 setTimezone() 之後。 WordPress 新增了自己的圖層: current_time('timestamp') 傳回一個假的"本地"時間戳與真實的 Unix 時間偏移,這和聽起來一樣危險。

蟒蛇:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

怪癖: fromtimestamp() 沒有 tz= 傳回本地時間的樸素日期時間。樸素的日期時間是 Python 時間錯誤:它們愉快地相互比較和減去,直到它們中的第一天跨越夏令時邊界。總是經過 tz=;使用 zoneinfo (自 3.9 起 stdlib)用於指定區域。

你應該如何處理時區而不失去理智?

四條規則,都學會了煩人的方式:

1. 儲存世界標準時間。總是。 Unix 時間戳或 timestamptz 在資料庫中。時區僅成為顯示問題。
2. 在表示層轉換。 達卡的用戶看到了 +06:00,柏林的用戶看到了 +02:00,資料庫看不到兩者。
3. 使用 IANA 名稱,而不是縮寫。 Asia/Dhaka, America/New_York, Europe/Berlin. 縮寫含糊不清 - CST 指美國中部、中國標準時間或古巴標準時間,取決於 who'閱讀 - 和縮寫 don't 編碼 DST 規則。 IANA 名稱確實如此。
4. 切勿手動滾動 DST 邏輯。 夏令時日期因國家而異,因立法而異,有些地方(亞利桑那州、孟加拉國、日本)完全遵守夏令時。 IANA tz 資料庫的存在是因為這確實很難;使用包裝它的庫。

規則 1 的推論:當兩個系統對事件時間有分歧時,將兩個值轉換為 UTC Unix 時間戳並比較整數。關於 &quot 的爭論;但這裡說下午 3 點 "立即溶解。

Y2038 問題是什麼?你應該關心嗎?

32 位元有符號整數的最大值為 2,147,483,647. 作為 Unix 時間戳,即 's 世界標準時間 2038 年 1 月 19 日 03:14:07. 一秒鐘後,該值為負值 - 到 1901 年 12 月 13 日。

聽起來很遙遠;它是't,原因有二。首先,它'當我寫這篇文章時,大約需要 11.5 年--這是在嵌入式系統、工業控制器的生命週期內,以及沒有人願意接觸的一項傳統服務。第二, 未來 日期很早就遇到了困難:計算 15 年抵押貸款計劃或 20 年期證書到期的系統將於 2038 年到期 今天. MySQL's TIMESTAMP 列類型是經典的陷阱 - it's 32 位元有界且 can't 儲存日期超過 2038 年 1 月 19 日,而 DATETIME 在同一個資料庫裡就可以了。

你'在 64 位元上安全 time_t (任何現代作業系統)、javascript(float64 ms)、Python(任意精度)和 PostgreSQL。 You'舊的 32 位元嵌入式系統面臨風險 TIMESTAMP 列和硬編碼的 C 代碼 int32_t 為了時間。測試很簡單:推 2147483648 (超過極限)通過你的管道,看看會發生什麼。這 時間戳轉換器 將很樂意為您產生 2038 年後的測試值。

真實調試中時間戳在哪裡顯示?

JWT 到期。 代幣攜帶 iat 和 exp 聲稱 Unix 秒:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

&引用;為什麼這個用戶被註銷了? &引用;透過轉換來回答 exp. 解碼中的令牌 中國航空解碼器 並轉換聲明 - 兩者都運行客戶端,這很重要,因為貼上的令牌是即時憑證(the) 資料隱私指南 涵蓋為什麼我拒絕在伺服器端工具中放置令牌)。

對數相關性。 一次事件,三項服務,三種格式:nginx 日誌 [13/Jul/2026:09:30:45 +0000],應用程式記錄 ISO 8601,佇列工作人員記錄原始紀元秒數。將所有內容轉換為一種格式是建立時間軸的步驟零。

API 整合。 條紋發送 "created": 1740470400 (秒)。 JavaScript 建構的 API 發送 1740470400000 (女士)。 Google API 發送 RFC 3339 字串。如果您消耗所有三個,則轉換是 't 偶爾 - it's 常數。格式化有效負載 json 格式化程式 並轉換有趣的字段。

日期範圍查詢。 WHERE created_at >= 1752364800 AND created_at < 1752451200- 那是正確的一天嗎?轉換界限並檢查, 在世界標準時間,在運行刪除之前。相關: 日期差計算器 對於"這兩者之間相隔多少天?&引用;, 時區轉換器 對於會議時間數學,以及 克朗解析器 對於"這個時間表什麼時候真正啟動?&報價;。

常見問題

什麼是 Unix 時間戳？

自 1970 年 1 月 1 日 00:00:00 UTC(Unix 紀元)以來經過的秒數,儲存為單一整數。 It'根據定義,時區與時區無關 - 地球上任何地方的同一瞬間都是相同的數字 - 這就是為什麼它'是跨作業系統、語言和資料庫的標準交換格式。

為什麼有些時間戳記有 10 位數字,有些則有 13 位數字?

10 位數字是秒(標準 Unix 約定、PHP、大多數 API); 13 位數字是毫秒 (JavaScript's) Date.now(),爪哇)。除以 1,000 從毫秒到秒。混淆兩班制的日期要么是 55,000 年後的未來,要么是 1970 年 1 月。

Unix 時間戳記可以代表 1970 年之前的日期嗎?

是的 - 負值從紀元開始倒數。 -86400 是 1969 年 12 月 31 日。32 位元簽名時間戳可以追溯到 1901 年 12 月 13 日。不過,有些系統和 API 拒絕否定時間戳,因此在依賴它們之前進行測試。

Y2038有什麼問題?

32 位元簽名時間戳溢位時間為2,147,483,647 - 2038 年1 月19 日,03:14:07 UTC - 截止至1901 年12 月。現代64 位元系統不受影響,但32 位元嵌入式裝置、舊版C 程式碼和MySQL TIMESTAMP 列暴露了。計算遙遠未來日期(抵押貸款、證書)的系統在 2038 年到來的幾年前就遇到了錯誤。

為什麼我的日期顯示為 1970 年 1 月?

零或接近零的時間戳到達您的格式代碼 - 通常是未初始化的值、返回 0 的失敗解析或預期經過的秒數。螢幕上的 1970 年日期幾乎從來都不是資料點;它'穿著服裝的空。

我應該將時間戳記或日期時間字串儲存在資料庫中嗎?

無論哪種方式儲存 UTC - 類型都比時區規則更重要。 Unix 整數緊湊、排序簡單且完全迴避解析; timestamptz/DATETIME 列在查詢結果中是人類可讀的,並支援 SQL 中的日期算術。您不能做的是儲存本地時間而不進行偏移 - that'資料遺失您只能在下一次 DST 轉換時發現。

紀元是否受到閏秒的影響?

實際上,沒有。 Unix 時間假裝閏秒 don'不存在 - 每天正好是 86,400 秒,系統通常在閏秒發生時塗抹或步進時鐘。對於應用程式程式碼來說,這不是問題;它僅在科學計時環境中很重要,即使用 TAI 或 GPS 時間。

將生產日誌時間戳貼到線上轉換器中安全嗎?

僅原始時間戳顯示的內容很少,但時間戳通常帶有上下文 - 使用者 ID、令牌聲明、日誌行。這 時間戳轉換器 在 toolz。dev 上,完全在瀏覽器中轉換,不會傳輸任何數據,因此直接從生產日誌或 JWT 中貼上值不會't 暴露任何東西。

如何將 Unix 時間戳轉換為可讀日期?

將數字貼到轉換器中並讀取 UTC 和本地結果,或用代碼進行: new Date(ts * 1000).toISOString() 在 JavaScript 中, datetime.fromtimestamp(ts, tz=timezone.utc) 在python中, date -u -d @ts 在 Linux 上。首先要正確的一件事是你的值是以秒還是毫秒為單位 - 其他一切都由此而來。

如何取得目前的 Unix 時間戳記?

date +%s 在貝殼裡, Math.floor(Date.now() / 1000) 在 JavaScript 中, int(time.time()) 在python中, SELECT EXTRACT(EPOCH FROM NOW()) 在 PostgreSQL 中。請注意,JavaScript 是奇數: Date.now() 傳回毫秒,因此除法不是可選的。