對照表
| 時間 | 秒 |
| 1 分鐘 | 60 |
| 1 小時 | 3600 |
| 1 天 | 86400 |
| 1 周 | 604800 |
| 1 月 (30.44 天) | 2629743 |
| 1年 (365.24 天) | 31556736 |
編程調用
類UNIX獲取時間戳 編程中獲取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() 返回1476929706.5320001 可以 int(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/類UNIX/OS X | date +%s |
| VBScript / ASP | DateDiff("s", "01/01/1970 08:00:00", Now()) |
| lua | os.time() 返回時間戳 |
| FreeSWITCH | fs_cli > strepoch 或者： fs_cli > eval ${strepoch()} 或者： （在 freeswitch裡面，獲取linux系統的時間戳） fs_cli > system date +%s |
| 其他作業系統 (如果Perl被安裝在系統中) | 命令行狀態：perl -e "print time" |
相關漏洞
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年事件”其中一種方法。
