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"