理解 Unix 时间戳
Unix 时间戳看起来简单,因为只是数字,但在 Web 工作中几乎无处不在。API、日志、导出、队列消息和事件记录都依赖它。其格式只是一个从 1970 年 1 月 1 日 UTC 开始计数秒(或毫秒)的整数。
它的优势是一致性。时间戳紧凑,在存储层与时区无关,软件比较、排序或传输都很方便。问题是它本身并不易读:像 1710153600 这样的值,在转换为日期之前没有任何含义。
因此,即使对资深开发者而言,时间戳工具依然有用。你常常需要快速回答这些实用问题:这是秒还是毫秒?它在 UTC 和本地时间分别对应哪一天?用于测试请求的某个特定日期对应的时间戳是多少?
什么时候会有用
- 查看返回如
created_at或expires_at等数字时间字段的 API 响应。 - 检查事件时间以原始 Unix 值存储的日志。
- 调试后端服务与浏览器之间的时区问题。
- 在测试请求或负载之前,把人类可读的日期转换为 Unix 时间。
实际示例
假设某个 API 在 JSON 负载中发送了 1710153600。乍一看,这个数字什么都说明不了,但转换之后就能看出它对应一个具体的 UTC 日期,以及你所在时区的本地日期。这样你立刻就能判断该值是否合理,或是否偏差了几小时、几天,甚至差了一千倍的量级。
毫秒在这里也很关键。像 1710153600000 这样的值表示的是同一个时刻,但单位是毫秒而不是秒。如果把一个当成另一个,日期就会完全错。
常见使用场景
- 检查负载中的时间戳字段使用的是秒还是毫秒。
- 将 UTC 中的事件时间与用户在本地时间看到的进行比较。
- 为测试和演示生成示例过期值。
- 验证后端和前端代码采用相同方式进行转换。
- 无需打开单独的控制台或脚本就可以阅读旧的导出数据。
使用浏览器中的转换器
使用浏览器中的工具,几秒钟就能完成这件事。
常见问题
为什么时间戳使用 UTC?
UTC 为软件提供一个稳定的参考点。可读的本地版本会随时区变化,但存储的时间戳不会变。
为什么有的时间戳是 10 位,有的是 13 位?
通常 10 位表示秒,13 位表示毫秒。
我一定要同时使用 UTC 和本地时间吗?
在调试时通常需要。UTC 便于跨系统比较,本地时间则有助于确认用户实际看到了什么。