unix時間戳

簡介

UNIX時間戳的0按照ISO8601規範為：1970-01-01T00:00:00Z.

一個小時表示為UNIX時間戳格式為：3600秒；一天表示為UNIX時間戳為86400秒，閏秒不計算。

在大多數的UNIX系統中UNIX時間戳存儲為32位，這樣會引發2038年問題或Y2038。

相關漏洞

64位iOS系統負時間值問題

計算原理（打開看）

計算原理（打開看）

搭載64位處理器的iOS設備的時間bug。

假設一種情況，我原來是北京時區，假設将時間設置到了1970年1月1日0點0時0秒，那麼我将這個時間轉換為UTC時間，公式：北京時間=GMT+8=UTC+8，那麼UTC時間則為1969年12月31日16時0分0秒。這樣就會出現時間負值，即時間回歸bug觸發，系統啟動卡在Kernel階段，時間錯誤，無法繼續進行啟動。

那麼既然時間不能往前調，好奇的朋友可能會往後調，當我們往後調的時候會發現iOS系統可以設置的最大時間是2038年1月1日，并不能再往後設置了。為什麼時間隻能調到這裡？

我們了解一下在32位系統中，time_t是長度為32位的，有符号整數（signed int）類型。首個二進制位是符号位，用來儲存正負。正數則為1970/1/1以後的時間，負數反之；其餘的31位用來記數。當時間到達2038年1月19日3時14分08秒(北京時間2038年1月19日11時14分08秒)時，數值位全部向前進1，導緻符号位被置1，其餘31位為0。介時，将出現“時間回歸”的情況，系統時間變為1901年12月13日20時45分52秒，系統将會出現錯誤。

1970年1月1日就像病毒一樣在世界蔓延開來了，不僅很多國外網友中招，在國内有很多iPhone用戶也都嘗試了。筆者剛剛看到關于1970年變磚的視頻後，内心是不相信的，覺得這個視頻後半段開機畫面是被剪掉了，然後筆者就手賤的進行了嘗試，把時間設置成1970年1月1日，手機關機重啟真的停留在白蘋果了，變“磚頭”了，真是應了這句話“不作就不會死”。

然後小編隻能用僅有的一點手機維修的功底，把手機拆開，斷開電池與主闆的連接，為了保險起見等待了十分鐘，重新連接電池，然後開機就正常了，這隻是解決“蘋果1970年事件”其中一種方法。

時間數據

時間

秒

1 分鐘

60

1 小時

3600

1 天

86400

1 周

604800

1 月 (30.44 天)

2629743

1年 (365.24 天)

31556926

編程調用

編程中獲取Unix時間戳

Java

time

JavaScript

Math.round(new Date().getTime()/1000)

getTime()返回數值的單位是毫秒

Microsoft .NET / C#

epoch = (DateTime.Now.ToUniversalTime().Ticks - 621355968000000000) / 10000000

MySQL

SELECT unix_timestamp(now())

Perl

time

PHP

time()

PostgreSQL

SELECT extract(epoch FROM now())

Python

先 import time 然後 time.time()

Ruby

獲取Unix時間戳：Time.now 或 Time.new

顯示Unix時間戳：Time.now.to_i

SQL Server

SELECT DATEDIFF(s, '1970-01-01 00:00:00', GETUTCDATE())

Unix / Linux

date +%s

VBScript / ASP

DateDiff("s", "01/01/1970 08:00:00", Now())

lua

os.time() 返回時間戳

FreeSWITCH

fs_cli > strepoch

或者：

fs_cli > eval ${strepoch()}

其他操作系統

(如果Perl被安裝在系統中)

命令行狀态：perl -e "print time"