Unix 时间戳详解

在日志检索、接口鉴权、缓存过期、分布式追踪里，你每天都会遇到Unix 时间戳。它把「某一瞬间」编码成一个数字，让不同时区、不同语言的程序用同一套尺子对话。下面从定义讲到工程实践与 2038 边界，并给出多语言取时间戳示例。

什么是 Unix 时间戳？

通常所说的 Unix 时间戳（Epoch time）指从 1970-01-01 00:00:00 UTC（Unix Epoch）到目标时刻经过的整秒数，不包含闰秒调整带来的「平滑」方案差异（一般业务可忽略）。在 Web 与移动开发中，还经常见到毫秒级时间戳，即秒数 ×1000，例如 JavaScript Date.now() 的返回值。

存储与传输时用时间戳，展示给用户时再格式化为本地日期字符串，是跨时区协作的最佳实践之一。

时间戳在开发中的应用

API：iat、exp 等 JWT 声明、OAuth 令牌过期、防重放窗口常以时间戳或由其派生的时间表达。
数据库：created_at、updated_at 常用 UTC datetime 或 BIGINT 存秒/毫秒，便于范围查询与排序。
日志与监控：统一用 UTC 或毫秒时间戳对齐多机事件，ELK、Prometheus 等栈都依赖这一约定。

常见编程语言获取时间戳

JavaScript

// 毫秒
const ms = Date.now();
// 秒（常用于与后端对齐）
const sec = Math.floor(Date.now() / 1000);

Python

import time
sec = int(time.time())          # 秒
ms = int(time.time() * 1000)    # 毫秒（近似）

Java

long ms = System.currentTimeMillis();
long sec = ms / 1000;

Go

import "time"
sec := time.Now().Unix()
ms := time.Now().UnixMilli()

2038 年问题

传统上若用 32 位有符号整数表示秒级 Unix 时间戳，最大值约为 2^31−1 秒，对应 UTC 约 2038 年 1 月 19 日 03:14:07，之后会发生溢出。现代操作系统、数据库与语言运行时大多已迁移到 64 位；遗留协议或嵌入式固件仍需审计。若你设计新协议，应明确整数位宽与单位（秒/毫秒/微秒）。

在线时间戳转换工具推荐

人工换算易混淆秒与毫秒、或忽略时区。即时工具 Unix 时间戳转换支持互转与可读日期对照，适合联调时快速核对。

打开时间戳转换工具

→ Unix 时间戳转换

常见问题（FAQ）

Unix 时间戳用秒还是毫秒？

经典 Unix 时间戳指自 1970-01-01 00:00:00 UTC 起的整秒数。JavaScript 的 Date.now() 与许多前端库默认毫秒，对接时务必确认单位，常见做法是与后端约定字段名如 created_at_ms。

为什么不直接用本地时区存储时间？

时间戳是绝对的 UTC 瞬时点，展示时再按用户时区格式化，可避免夏令时、历史时区规则变更带来的错乱。数据库与日志普遍存 UTC 或时间戳。

32 位有符号整数与时间有什么关系？

若用 32 位有符号整数存「秒级」时间戳，最大值对应约 2038-01-19 UTC，即「2038 年问题」。新系统应使用 64 位整数或更高精度类型。

如何在浏览器里快速校验时间戳？

可使用即时工具的在线转换页，输入秒或毫秒即可对照本地可读时间，减少心算错误。

把时间戳当作「协议层的通用时钟」，把格式化显示交给 UI 层，你的服务在扩展到全球用户时会轻松很多。