Unix 時間戳轉換器
時間戳轉日期
秒或毫秒會自動偵測。
日期轉時間戳
選擇日期和時間,將其轉換為Unix時間戳。
自 Unix 時代(1970年1月1日 00:00:00 UTC)以來的秒數
秒或毫秒會自動偵測。
選擇日期和時間,將其轉換為Unix時間戳。
同一當前時刻以多種常見格式即時更新顯示:
| 格式 | 目前數值 |
|---|---|
| Unix 時間戳記 (秒) | — |
| Unix 時間戳(毫秒) | — |
| ISO 8601 (UTC) | — |
| RFC 2822 (UTC) | — |
Unix 時間(也稱為 Epoch 時間、POSIX 時間或 Unix 時標)是一種描述時間點的系統。它是自 Unix 時代(定義為 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 epoch 是 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位元整数中。