如何转换 Unix 时间戳

Unix时间戳是计算机存储和传达时间的方式:一个表示自1970年1月1日以来秒数的单一数字。它们出现在API响应、数据库记录、日志文件和JWT令牌中。当您需要知道1711824000实际上是什么日期时,您需要一个转换器。基于浏览器的转换器立即处理数学运算,并允许您双向操作(时间戳到日期,日期到时间戳)。

Unix时间戳的样子

秒和毫秒的区别是三个额外的零。10位数字是秒;13位数字是毫秒。从2024年起,所有基于秒的Unix时间戳都是10位数字,并将一直保持到2286年11月。

如何转换时间戳

1. 输入时间戳或日期:粘贴Unix时间戳以转换为可读日期,或输入日期以获取时间戳。
2. 检查格式:转换器根据数字长度自动检测秒vs毫秒。
3. 读取结果:查看您本地时区、UTC和ISO 8601格式的日期。

Unix时间简史

Unix时间最早在1971年11月由Bell Labs发布的Unix程序员手册中定义。原始纪元是1971年1月1日,但不久之后改为1970年1月1日,并在POSIX.1(1988)中标准化。

选择1970年是任意的但实用的:Unix是在1969-1971年开发的,从操作系统诞生附近开始计数似乎是合理的。从1970年开始计数秒的32位有符号整数给出了从1901年12月到2038年1月的范围,设计者认为这就足够了。

事实并非如此。「2038年问题」(也称Y2K38)是32位有符号Unix时间戳溢出的时刻:在纪元后2147483647秒,下一个滴答翻转为系统解释为1901年12月的负数。大多数现代系统在2000年代和2010年代迁移到64位整数时间戳,但一些嵌入式设备、较旧的数据库和遗留文件格式仍使用32位时间,需要在2038年之前修补。

Unix时间现在是计算机系统中表示时间的事实标准。JSON API、数据库行时间戳、JWT过期、区块链区块时间、IoT传感器读数:几乎所有都直接或间接使用Unix纪元。

秒、毫秒、微秒、纳秒

不同的系统使用不同的精度:

• 秒(2024年为10位数字):经典Unix时间,POSIX标准,大多数API和数据库
• 毫秒(13位数字):JavaScript Date、Java System.currentTimeMillis()、许多Web API
• 微秒(16位数字):PostgreSQL timestamp、Python datetime(转换后)
• 纳秒(19位数字):Go time.UnixNano()、eBPF跟踪、高频交易系统

19位时间戳可能混淆期望毫秒的转换器;当您看到异常数字时,请仔细检查源文档。

您在哪里遇到时间戳

• API响应:大多数REST API将日期作为Unix时间戳返回:"created_at": 1711824000
• JWT令牌:iat(签发于)和exp(过期)声明是Unix时间戳
• 数据库记录:许多数据库将时间戳存储为整数以进行高效的排序和比较
• 日志文件:服务器日志通常以纪元时间戳为条目前缀
• Cron任务:调度系统以Unix格式引用时间
• 文件系统mtime/atime/ctime:Linux和macOS文件元数据使用Unix时间
• 区块链区块时间戳:每个比特币和以太坊区块都在其标头中具有Unix时间戳
• Cookies和HTTP标头:Max-Age、If-Modified-Since通常间接使用纪元数学

代码中的时间戳

常见语言中的快速转换:

JavaScript:

new Date(1711824000 * 1000)            // 来自秒(乘以1000)
new Date(1711824000000)                // 来自毫秒
Math.floor(Date.now() / 1000)          // 当前时间(秒)
Date.now()                             // 当前时间(毫秒)

Python:

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # 当前时间(秒,float)

Bash:

date -u -d @1711824000                 # GNU date(Linux)
date -u -r 1711824000                  # BSD date(macOS)
date +%s                               # 当前时间(秒)

SQL(PostgreSQL):

SELECT TO_TIMESTAMP(1711824000);       -- 将纪元转换为时间戳
SELECT EXTRACT(EPOCH FROM NOW());      -- 当前纪元

Go:

time.Unix(1711824000, 0)               // 来自秒
time.Now().Unix()                      // 当前时间(秒)

时区处理

这是大多数时间戳错误隐藏的地方:

• Unix时间戳始终是UTC。没有「本地时间」的Unix时间戳。数字本身是绝对的。
• 显示时区很重要。同一个时间戳1711824000显示为:
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT(洛杉矶,UTC-7)
  • 2024-03-31 09:00:00 JST(东京,UTC+9)
• DST转换很棘手。像「2024-03-10 02:30:00 EST」这样的本地时间不存在(时钟从02:00跳到03:00)。转换器以不同方式处理这一点;有些返回错误,有些舍入到03:30,有些转换为标准时间。
• 闰秒被忽略。Unix时间假装每分钟正好有60秒。真实的UTC偶尔会插入闰秒(最后一次是2016年)。对于99%的使用,这没问题;对于精密天文学或原子钟,这很重要。

在API中发送时间戳时,始终使用UTC秒。向用户显示时,转换为他们的本地时区。转换器处理两个方向。

常见陷阱

• JavaScript Date()构造函数接受毫秒,而不是秒:第一名时间戳错误。new Date(1711824000)将该数字解释为1970年1月20日,因为JS将其读为毫秒。您需要new Date(1711824000 * 1000)。
• 混淆Unix时间和Excel/Google Sheets日期编号:Excel使用不同的纪元(1899年12月30日)并计算天数,而不是秒数。将Unix时间戳导入日期列将显示错误的日期。
• 负时间戳:1970年1月1日之前的日期表示为负Unix时间戳。一些转换器和数据库拒绝它们;其他人则正确处理。
• 遗留代码中的2038年:32位有符号整数时间戳在2038年1月19日03:14:07 UTC溢出。大多数现代系统使用64位,但请检查嵌入式设备、旧SQLite数据库和32位操作系统。
• 依赖于区域设置的日期解析:「03/04/2024」在美式英语中是3月4日,在英式英语中是4月3日。始终在系统之间传递时间戳(或ISO 8601字符串);切勿传递区域设置格式的字符串。
• 亚秒精度损失:在秒精度字段中存储毫秒时间戳会丢失最后3位数字。某些API同时返回两种格式(created_at以秒为单位,created_at_ms以毫秒为单位)以避免这种情况。

提示

• JavaScript乘以1000:JS Date需要毫秒,但大多数API返回秒。忘记乘是最常见的时间戳错误。
• 始终指定UTC:转换时,明确时区。「3月31日午夜」根据您指的是UTC、EST还是PST是不同的时间戳。
• 使用ISO 8601进行显示:转换后,将日期格式化为2024-03-31T00:00:00Z,以在时区之间进行明确的通信。
• 书签转换器:如果您使用API或数据库,您将经常转换时间戳,以至于希望一键即可。
• 往返以验证:有疑问时,将您的时间戳转换为日期,然后将日期转换回时间戳。如果您得到相同的数字,您的理解是正确的。
• 注意数字的位数:10 = 秒,13 = 毫秒,16 = 微秒,19 = 纳秒。如果您的数学差了1000或1000000倍,您有精度不匹配。

隐私

Unix时间戳转换器完全在您的浏览器中运行。您输入的时间戳和日期永远不会离开您的设备。这很重要,因为时间戳可能很敏感:它们可能来自揭示内部基础设施时序的日志文件、带有嵌入式用户/会话信息的JWT令牌、不应与第三方共享的内部API调试。云时间戳转换器可能会出于「改进」目的记录输入;仅浏览器转换器具有零暴露。

基于浏览器的转换在页面加载后也可以离线工作,并且足够快,您可以将时间戳放入字段并在同一时刻看到日期。