Unix 時間戳轉換器
時間戳轉日期
秒或毫秒會自動偵測。
日期轉時間戳
選擇一個日期和時間,將其轉換為 Unix 時間戳。
自 Unix 時代(1970年1月1日 00:00:00 UTC)以來的秒數
秒或毫秒會自動偵測。
選擇一個日期和時間,將其轉換為 Unix 時間戳。
以下多個常用格式顯示的同一當前時刻,即時更新:
| 格式 | 目前數值 |
|---|---|
| Unix 時間戳(秒) | — |
| Unix 時間戳(毫秒) | — |
| ISO 8601 (世界標準時間) | — |
| RFC 2822(協調世界時) | — |
Unix 時間(亦稱為 Epoch 時間、POSIX 時間或 Unix 時標)是一種描述時間點的系統。它是自 Unix Epoch(定義為 1970 年 1 月 1 日星期四 UTC 00:00:00)以來經過的秒數。它在類 Unix 作業系統和許多其他計算系統中被廣泛使用。
Unix 時間的主要優點是其簡單性。它以一個單一、普遍理解的整數來表示時間,並且這個數值會持續增加。這使得存儲、比較和計算時間戳變得非常容易,而不必擔心時區、夏令時間或不同的日曆系統。例如,要找出兩個事件之間的持續時間,只需相減它們的 Unix 時標即可。
雖然這個原始數字對電腦來說非常適合,但對人類來說並不太友善。為了彌合這個差距,開發者和科技愛好者會使用一個叫做 時標轉換器 的工具。你可以用它即時將任何時間戳轉換成易讀的日期,或反向操作,找到特定日期的時間戳。
一個與 Unix 時間相關的著名問題是「2038 年問題」。它與 Y2K 問題類似。許多早期的電腦系統被設計為將 Unix 時標存儲為 32 位帶符號整數。一個帶符號的 32 位整數可以表示的範圍是從 -2,147,483,648 到 2,147,483,647。
最大值 2,147,483,647 將在 2038 年 1 月 19 日 UTC 03:14:07 達到。下一秒,整數將溢出並回繞到其最小值,系統會將其解讀為 1901 年的日期。這可能導致依賴 32 位時間表示的舊版軟體出現廣泛故障。
解決方案是使用 64 位整數來存儲時間戳。64 位整數的最大值非常大,大約可以存放 292 億年,從而有效解決未來可預見的問題。大多數現代作業系統和軟體已經轉向使用 64 位時間表示。
一個重要的技術細節是 Unix 時間不考慮閏秒。雖然 UTC(協調世界時)偶爾會加入閏秒以保持與地球自轉同步,Unix 時標則完全忽略它們,並持續線性計數。
這意味著 Unix 時間並非真正的 UTC 表示。更準確地說,它是秒數的線性累計。當閏秒出現時,Unix 時間有時會重複一秒以保持同步。這個細微差別對科學和高精度應用非常重要,但對大多數一般用途的計算來說,差異可以忽略。
created_at、updated_at)日期和時間資訊的常用且高效的方法。
Unix 紀元是 Unix 系統的時間起點:1970 年 1 月 1 日 00:00:00 UTC。Unix 時間戳就是自該時刻以來經過的秒數。
該日期由Unix的早期開發者選擇,作為一個方便、整數的起點,接近系統在1970年代初期創建之時。自此成為標準的參考點。
Unix時間從定義為UTC的紀元開始計算,與時區無關,因此相同的時間戳在世界各地代表相同的瞬間。由於它忽略閏秒,因此最適合描述為一個線性的秒數計數,而非UTC的完美表示。
標準Unix時間戳從紀元開始計算整秒,目前日期為10位數字。許多系統,包括JavaScript,改用毫秒計算,產生一個大1,000倍的值,有13位數字。
將時間戳儲存為32位元有符號整數的系統只能計算到2038年1月19日03:14:07 UTC,之後數值會溢位,並被誤讀為1901年的日期。解決方法是將時間戳儲存為64位元整數。