Unix 时间戳详解：什么是纪元时间，开发者如何使用它
学习什么是 Unix 时间戳、纪元时间的工作原理，以及开发者为何使用它。包含 Python、JavaScript、PHP、Java、SQL、Go 和 Bash 七种语言的编程示例，并解释 Y2K38（2038 年问题）。
Unix 时间戳详解：什么是纪元时间，开发者如何使用它
Unix 时间戳无处不在——数据库字段、API 响应、日志文件、JWT 令牌、文件系统、HTTP 头部，处处可见——却很少有人真正讲清楚它是什么。第一次遇到 1710892800 这样的值时，它看起来毫无意义，但它精确编码了一个时刻，任何编程语言、任何操作系统都能无歧义地解读。
本文解释什么是 Unix 时间戳，它为何成为计算机中表示时间的标准方式，以及如何在七种编程语言中操作它。无论你在构建 REST API、调试 cron 任务，还是试图读懂数据库转储里的时间戳，理解纪元时间都能为你省去大量困惑。如果需要快速将 Unix 时间戳转换为人类可读日期（或反向转换），可以试试我们的 Unix 时间戳转换工具——它自动处理秒级、毫秒级和微秒级时间戳。
什么是 Unix 时间戳？
Unix 时间戳是一个整数，表示某个特定时刻。它记录自 1970 年 1 月 1 日 00:00
世界协调时间（UTC） 起所经过的秒数。这个固定起点称为 Unix 纪元（Unix epoch），该计时方式称为 Unix 时间、POSIX 时间，或简称纪元时间。举例来说，Unix 时间戳 1000000000 对应 2001 年 9 月 9 日 01:46
0 就是纪元本身：1970 年 1 月 1 日午夜；时间戳 86400 表示纪元后恰好一天，因为一天有 86400 秒（60 秒 × 60 分钟 × 24 小时）。
选择 1970 年 1 月 1 日并非随意。Unix 操作系统由 Ken Thompson、Dennis Ritchie 等人于 20 世纪 60 年代末至 70 年代初在贝尔实验室开发。早期 Unix 系统需要一种紧凑的方式存储文件修改时间，工程师选择了一个接近系统诞生年份的日期。Unix 纪元最初是 1971 年 1 月 1 日，后来往前移至 1970 年 1 月 1 日，以获得更整齐的起点和更大的表示范围。当时使用的 32 位计数器从 1970 年起可以表示到 2038 年，在那个年代显得遥不可及。
「纪元」在计算机中仅仅意味着一个固定的时间参考点。不同系统使用不同纪元——Windows 用 1601 年 1 月 1 日，Mac OS 经典版用 1904 年 1 月 1 日，NTP 用 1900 年 1 月 1 日——但 Unix 的 1970 年纪元是现代软件开发中使用最广泛的。
开发者为何使用 Unix 时间戳
Unix 时间戳成为软件中主流时间表示方式，有几个解决实际工程问题的实用原因。
时区无关性。 Unix 时间戳始终是 UTC。当 API 返回 1710892800 时，无论服务器在东京、客户端在伦敦，还是数据库托管在弗吉尼亚，这个值的含义完全相同。无需解析时区偏移，无需处理夏令时切换，也不会产生「下午 3 点」到底是东部时间还是太平洋时间的歧义。转换为本地时间的操作只在展示层发生。
算术运算简单。 想知道两个事件之间经过了多少秒？直接相减。需要安排 24 小时后的任务？加上 86400。需要检查令牌是否过期？用小于运算符比较到期时间戳和当前时间。无需日期解析库。
语言和平台无关性。 每种主流编程语言都内置了处理 Unix 时间戳的函数：Python 有 time.time()，JavaScript 有 Date.now()，PHP 有 time()，Java 有 System.currentTimeMillis()，Go 有 time.Now().Unix()，SQL 数据库有 UNIX_TIMESTAMP() 或 EXTRACT(EPOCH FROM ...)。这种通用性使 Unix 时间戳成为不同语言系统之间数据交换的自然选择。
存储紧凑。 秒级 Unix 时间戳可以存入 32 位或 64 位整数，即 4 或 8 个字节，而 2025-03-20T00:00:00Z 这样的 ISO 8601 字符串需要 19 个字节以上。对于有数百万行的数据库，这种差异对存储和索引性能都有实际影响。
排序和比较无歧义。 整数比较比字符串比较更快、更简单。不会出现日期字符串排序 bug——"03/04/2025" 根据区域设置可能意味着 3 月 4 日或 4 月 3 日。使用日期计算器可以验证任何日期运算，而 Unix 时间戳在代码层面让数学运算直接正确。
Unix 时间的工作原理
Unix 时间是一个线性单调递增的秒计数器。在纪元（1970 年 1 月 1 日 00:00
UTC）时，计数器为零。此后每过一秒，计数器加一。当前 Unix 时间戳约为 17.7 亿，意味着自纪元以来约经过了 17.7 亿秒。计数是线性的，每一秒都一视同仁：没有闰年的间隙，没有夏令时调整，也——存在争议地——没有闰秒的处理。就 POSIX 时间而言，每天恰好 86400 秒，每小时恰好 3600 秒，每分钟恰好 60 秒。这是一种刻意的简化，以计算简便换取天文精度。
负时间戳表示纪元之前的时刻。时间戳 -86400 对应 1969 年 12 月 31 日 00:00
-2208988800 对应 1900 年 1 月 1 日午夜 UTC。负时间戳完全有效，大多数编程语言都支持，但某些旧系统和数据库可能无法正确处理。
可以把 Unix 时间想象成一条以零为原点向两端延伸的数轴：
... -86400 ─── 0 ─── 86400 ─── 172800 ...
Dec 31 Jan 1 Jan 2 Jan 3
1969 1970 1970 1970
每个刻度间隔一秒，数轴向左延伸可以表示任何历史日期，向右延伸直到系统整数大小耗尽。对于 32 位有符号整数，数轴在 2,147,483,647（2038 年 1 月 19 日）处终止；对于 64 位有符号整数，则可向两端延伸约 2920 亿年——远超宇宙年龄。
秒级 vs 毫秒级 vs 微秒级
并非所有「Unix 时间戳」都有相同的精度。当你遇到一个表示时间点的大数字时，位数可以告诉你它使用的单位。
10 位：秒级。 这是经典的 Unix 时间戳，当前值形如 17xxxxxxxx。Unix/Linux 系统调用、PHP 的 time()、Python 的 int(time.time())、MySQL 的 UNIX_TIMESTAMP()，以及 PostgreSQL 的 EXTRACT(EPOCH FROM ...) 均返回秒级时间戳。这是数据库和 API 中最常见的格式。
13 位：毫秒级。 当前值形如 17xxxxxxxxxxx。JavaScript 的 Date.now() 和 Java 的 System.currentTimeMillis() 默认返回毫秒。许多现代 API 和前端框架使用毫秒级时间戳。转换为秒级时除以 1000，转换为毫秒级时乘以 1000。
16 位：微秒级。 值形如 17xxxxxxxxxxxxxx。Python 的 time.time() 返回含微秒精度的浮点数。部分高精度日志系统和科学应用使用微秒级时间戳。转换为秒级时除以 1,000,000。
19 位：纳秒级。 值形如 17xxxxxxxxxxxxxxxxx。Go 的 time.Now().UnixNano() 返回纳秒。纳秒精度用于性能分析、分布式追踪系统和高频交易平台。转换为秒级时除以 1,000,000,000。
如何自动区分精度： 数位数。如果你在编写必须接受任意精度时间戳的代码，有一个简单启发规则：
10 位 → 秒级 （正值范围约为 1973—2286 年）
13 位 → 毫秒级 （正值范围约为 1973—2286 年）
16 位 → 微秒级 （正值范围约为 1973—2286 年）
19 位 → 纳秒级 （正值范围约为 1973—2286 年）
10 位时按秒处理；13 位时除以 1000 归一化为秒。这一规律是一致的，因为「感兴趣」的日期范围（近期过去到不远的将来）总是落在这些位数区间内。我们的 Unix 时间戳转换工具就采用这种方法自动检测精度。
各编程语言中的 Unix 时间戳
以下是七种语言中最常见时间戳操作的实用代码示例。每节展示如何获取当前时间戳、将时间戳转换为人类可读日期，以及将日期转换为时间戳。
Python
import time
from datetime import datetime, timezone
# 获取当前 Unix 时间戳（含微秒精度的浮点数）
timestamp = time.time() # 例如 1710892800.123456
timestamp_int = int(time.time()) # 例如 1710892800
# 时间戳转 datetime（UTC）
dt = datetime.fromtimestamp(1710892800, tz=timezone.utc)
print(dt) # 2024-03-20 00:00:00+00:00
print(dt.strftime('%Y-%m-%d %H:%M:%S')) # 2024-03-20 00:00:00
# datetime 转时间戳
dt = datetime(2024, 3, 20, tzinfo=timezone.utc)
ts = int(dt.timestamp()) # 1710892800
# 日期字符串转时间戳
from datetime import datetime
dt = datetime.strptime("2024-03-20 15:30:00", "%Y-%m-%d %H:%M:%S")
dt = dt.replace(tzinfo=timezone.utc)
ts = int(dt.timestamp())
JavaScript
// 获取当前 Unix 时间戳（毫秒级）
const nowMs = Date.now(); // 例如 1710892800000
// 获取当前 Unix 时间戳（秒级）
const nowSec = Math.floor(Date.now() / 1000); // 例如 1710892800
// 时间戳（秒级）转 Date 对象
const date = new Date(1710892800 * 1000); // 注意：JS 需要毫秒
console.log(date.toISOString()); // "2024-03-20T00:00:00.000Z"
console.log(date.toLocaleString()); // 取决于本地区域设置
// 日期转时间戳（秒级）
const ts = Math.floor(new Date('2024-03-20T00:00:00Z').getTime() / 1000);
// ts = 1710892800
// 时间戳转格式化字符串（无需第三方库）
const formatted = new Intl.DateTimeFormat('en-US', {
dateStyle: 'full',
timeStyle: 'long',
timeZone: 'America/New_York'
}).format(new Date(1710892800 * 1000));
PHP
<?php
// 获取当前 Unix 时间戳
$timestamp = time(); // 例如 1710892800
$microtime = microtime(true); // 例如 1710892800.123456
// 时间戳转格式化日期
echo date('Y-m-d H:i:s', 1710892800); // "2024-03-20 00:00:00"
echo gmdate('Y-m-d H:i:s', 1710892800); // UTC: "2024-03-20 00:00:00"
// 日期字符串转时间戳
$ts = strtotime('2024-03-20 00:00:00 UTC'); // 1710892800
// 使用 DateTime 对象
$dt = new DateTime('2024-03-20', new DateTimeZone('UTC'));
$ts = $dt->getTimestamp(); // 1710892800
// 时间戳转 DateTime
$dt = new DateTime();
$dt->setTimestamp(1710892800);
echo $dt->format('Y-m-d H:i:s T');
Java
import java.time.*;
// 获取当前 Unix 时间戳（秒级）
long epochSecond = Instant.now().getEpochSecond(); // 例如 1710892800
// 获取当前 Unix 时间戳（毫秒级）
long epochMilli = System.currentTimeMillis(); // 例如 1710892800000
// 时间戳转 LocalDateTime（UTC）
LocalDateTime ldt = LocalDateTime.ofInstant(
Instant.ofEpochSecond(1710892800), ZoneOffset.UTC
);
System.out.println(ldt); // 2024-03-20T00:00
// 时间戳转 ZonedDateTime（带时区）
ZonedDateTime zdt = Instant.ofEpochSecond(1710892800)
.atZone(ZoneId.of("America/New_York"));
System.out.println(zdt); // 2024-03-19T20:00-04:00[America/New_York]
// 日期转时间戳
long ts = LocalDateTime.of(2024, 3, 20, 0, 0, 0)
.toEpochSecond(ZoneOffset.UTC); // 1710892800
SQL（MySQL 与 PostgreSQL）
-- MySQL：获取当前 Unix 时间戳
SELECT UNIX_TIMESTAMP(); -- 例如 1710892800
SELECT UNIX_TIMESTAMP('2024-03-20 00:00:00'); -- 1710892800
-- MySQL：时间戳转日期时间
SELECT FROM_UNIXTIME(1710892800); -- '2024-03-20 00:00:00'
SELECT FROM_UNIXTIME(1710892800, '%Y-%m-%d'); -- '2024-03-20'
-- PostgreSQL：获取当前 Unix 时间戳
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT; -- 例如 1710892800
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-03-20 00:00:00')::BIGINT;
-- PostgreSQL：时间戳转日期时间
SELECT TO_TIMESTAMP(1710892800); -- '2024-03-20 00:00:00+00'
SELECT TO_TIMESTAMP(1710892800) AT TIME ZONE 'US/Eastern';
-- 筛选最近 24 小时的行（MySQL）
SELECT * FROM events
WHERE created_at >= UNIX_TIMESTAMP() - 86400;
-- 筛选最近 24 小时的行（PostgreSQL）
SELECT * FROM events
WHERE created_at >= EXTRACT(EPOCH FROM NOW()) - 86400;
Go
package main
import (
"fmt"
"time"
)
func main() {
// 获取当前 Unix 时间戳
sec := time.Now().Unix() // 秒级，例如 1710892800
ms := time.Now().UnixMilli() // 毫秒级
us := time.Now().UnixMicro() // 微秒级
ns := time.Now().UnixNano() // 纳秒级
// 时间戳转 time.Time
t := time.Unix(1710892800, 0).UTC()
fmt.Println(t) // 2024-03-20 00:00:00 +0000 UTC
fmt.Println(t.Format("2006-01-02 15:04:05")) // 2024-03-20 00:00:00
fmt.Println(t.Format(time.RFC3339)) // 2024-03-20T00:00:00Z
// 日期转时间戳
t2 := time.Date(2024, 3, 20, 0, 0, 0, 0, time.UTC)
ts := t2.Unix() // 1710892800
fmt.Println(sec, ms, us, ns, ts)
}
Bash / Shell
# 获取当前 Unix 时间戳
date +%s # 例如 1710892800
# 时间戳转人类可读日期（GNU/Linux）
date -d @1710892800 # Wed Mar 20 00:00:00 UTC 2024
date -d @1710892800 '+%Y-%m-%d %H:%M:%S' # 2024-03-20 00:00:00
# 时间戳转人类可读日期（macOS/BSD）
date -r 1710892800 # Wed Mar 20 00:00:00 UTC 2024
date -r 1710892800 '+%Y-%m-%d' # 2024-03-20
# 日期字符串转时间戳（GNU/Linux）
date -d '2024-03-20 00:00:00 UTC' +%s # 1710892800
# 日期字符串转时间戳（macOS/BSD）
date -j -f '%Y-%m-%d %H:%M:%S' '2024-03-20 00:00:00' +%s
# 计算耗时
START=$(date +%s)
# ... 某项操作 ...
END=$(date +%s)
ELAPSED=$((END - START))
echo "操作耗时 ${ELAPSED} 秒"
Excel 和 Google Sheets 中的 Unix 时间戳
电子表格使用自己的日期序列号系统，但可以通过简单公式转换 Unix 时间戳。
Excel 或 Google Sheets 中时间戳转日期：
=(A1/86400)+DATE(1970,1,1)
该公式将时间戳除以 86400（一天的秒数）得到自纪元以来的天数，再加上纪元日期。将结果单元格格式设置为日期/时间即可看到可读的值。
日期转 Unix 时间戳：
=(A1-DATE(1970,1,1))*86400
该公式反向操作：计算日期与纪元之间相差的天数，再乘以 86400 得到秒数。
重要的时区注意事项： Excel 和 Google Sheets 本身不理解时区。上述公式假设时间戳为 UTC。如果你的电子表格日期是本地时区，需要通过加减 UTC 偏移量（以秒为单位）进行调整。例如，美国东部时间（UTC-5）：
=(A1/86400)+DATE(1970,1,1)-(5/24)
处理毫秒级时间戳： 如果数据包含 13 位毫秒级时间戳，将 86400 改为 86,400,000：
=(A1/86400000)+DATE(1970,1,1)
如需快速单次转换而无需构建电子表格，直接在浏览器中使用我们的 Unix 时间戳转换工具。
著名的 Unix 时间戳
某些 Unix 时间戳已成为计算机历史上令人难忘的里程碑，有些被程序员庆祝，有些则引发了真实的 bug。
| 日期（UTC） | Unix 时间戳 | 意义 |
|---|---|---|
| 1970 年 1 月 1 日 00:00 | 0 | Unix 纪元——Unix 时间的起点 |
| 2000 年 1 月 1 日 00:00 | 946,684,800 | Y2K / 2000 年翻转 |
| 2001 年 9 月 9 日 01:46 | 1,000,000,000 | 十亿秒——Unix 爱好者的庆典 |
| 2007 年 1 月 9 日 09:41 | 1,168,344,060 | Steve Jobs 发布初代 iPhone |
| 2009 年 3 月 13 日 23:31 | 1,234,567,890 | 顺序数字——全球举办「Unix 时间 1234567890」派对 |
| 2017 年 7 月 14 日 02:40 | 1,500,000,000 | 自纪元起 15 亿秒 |
| 2025 年 1 月 1 日 00:00 | 1,735,689,600 | 2025 年元旦 |
| 2033 年 5 月 18 日 03:33 | 2,000,000,000 | 20 亿秒 |
| 2038 年 1 月 19 日 03:14 | 2,147,483,647 | 32 位有符号整数最大值——Y2K38 临界点 |
2001 年的十亿秒里程碑在开发者社区广受关注，一些团队举办了类似 Y2K 庆典的「纪元秒」派对。2009 年的顺序数字时间戳 1234567890 更引发了更大的关注，全球各地出现了倒计时网站和 Unix 爱好者聚会。
2038 年问题（Y2K38）
2038 年问题是一个真实且已充分认识的 bug，影响所有以 32 位有符号整数存储 Unix 时间戳的系统。它有时被称为「Y2K38 bug」或「Unix 千年虫」，虽然没有 Y2K 那么戏剧性，但对未更新的系统仍有可能造成严重影响。
会发生什么
32 位有符号整数可以表示 -2,147,483,648 到 2,147,483,647 的值。最大正值 2,147,483,647 对应 2038 年 1 月 19 日 03:14
UTC。一秒后，整数溢出。它不会变成 2,147,483,648，而是回绕到 -2,147,483,648，系统将其解读为 1901 年 12 月 13 日 20:45 UTC。这不是假设性问题。任何比较时间戳、计算时长或调度未来事件的软件，在溢出后都会产生错误结果。2038 年创建的文件可能看起来比 2037 年创建的更旧；有效期到 2040 年的 SSL 证书可能显示为已过期超过一个世纪；设定为下周二的定时任务可能立即触发或永远不触发。
与 Y2K 的对比
Y2K bug 是由于用两位数字存储年份，导致 2000 年与 1900 年无法区分。Y2K38 bug 机制不同但概念相似：都是因为使用了超出范围的固定大小整数。Y2K 的修复主要是更新日期字符串格式，而 Y2K38 的修复需要在更深层次修改数据类型——系统调用、文件格式、数据库模式和二进制协议。
解决方案
原理上解决方案很简单：用 64 位整数替代 32 位整数。64 位有符号整数可以表示自纪元起约 2920 亿年的时间戳，足够使用。大多数现代 64 位操作系统——包括 Linux（内核 5.6 起所有内部接口）、macOS 和现代 Windows——已完成这一迁移。运行在 64 位系统上的编程语言通常默认使用 64 位时间值。
仍面临风险的系统
危险在于难以更新的系统：
- 嵌入式设备：使用 32 位处理器的工业控制器、医疗设备、汽车系统，2038 年时可能仍在运行
- 遗留数据库：使用 32 位整数时间戳列的系统（部分 MySQL 表用
INT而非BIGINT） - 二进制文件格式：在文件头中硬编码 32 位时间戳的格式
- 物联网设备：部署周期长、固件更新不频繁的设备
- 网络协议：在标准中规定 32 位时间戳字段的协议
如果你正在设计新系统，始终使用 64 位整数存储时间戳。如果在维护现有系统，请审查时间戳存储方式：检查数据库列类型、结构体定义和序列化格式。如需在字节层面验证时间戳的存储方式，可以使用十六进制转十进制转换工具检查原始二进制数据。
闰秒与 Unix 时间
Unix 时间最受争议的方面之一是对闰秒的处理。简短回答：POSIX 时间完全忽略闰秒。
在现实中，地球自转在逐渐减慢。为使 UTC 与地球实际自转保持同步，国际地球自转与参考系服务（IERS）偶尔会插入一个闰秒。1972 年至 2016 年间，共添加了 27 个闰秒。闰秒发生时，UTC 时钟在归零前会显示 23:59
——即一分钟有 61 秒。POSIX 时间假装这不存在。每天恰好定义为 86400 秒，每分钟恰好 60 秒。当现实中出现闰秒时，POSIX 时间要么重复一秒（同一时间戳值出现两次），要么将调整分散到附近几秒，具体取决于实现方式。谷歌的「闰秒平滑（leap smear）」方案将额外的一秒分散到 24 小时窗口内，使当天每一秒都比真实的一秒略长一点点。
对于绝大多数软件开发任务，这无关紧要。Unix 时间与精确 UTC 之间的差异在整个纪元内最多只有几秒，对日志条目时间戳、用户注册、API 限流或定时任务来说完全可以忽略。只有在构建卫星导航系统、天文观测软件，或需要相对于国际原子时（TAI）具有亚秒精度的金融交易平台时，才需要使用不同于 Unix 时间戳的时间表示方式。
值得一提的是，国际计量大会于 2022 年投票决定在 2035 年前废除闰秒，因此这整个问题在不远的将来可能变得无关紧要。
常见问题
Unix 时间戳可以是负数吗？
可以。负 Unix 时间戳表示 1970 年 1 月 1 日之前的日期。例如，-1 是 1969 年 12 月 31 日 23:59
-86400 是 1969 年 12 月 31 日 00:00 UTC。大多数现代编程语言能正确处理负时间戳，但部分系统和数据库不支持。例如，MySQL 的 FROM_UNIXTIME() 函数只接受非负值。如果需要处理 1970 年之前的历史日期，请测试你所用平台的具体行为。
Unix 时间戳的最大值是多少？
在 32 位系统上，最大 Unix 时间戳为 2,147,483,647（2038 年 1 月 19 日 03:14
UTC）。在 64 位系统上，最大值为 9,223,372,036,854,775,807（距今约 2920 亿年）。现代系统和编程语言默认使用 64 位时间值，实际限制可视为无穷大。你可以使用二进制转十进制转换工具验证大数字，查看二进制表示如何映射到整数最大值。Unix 时间与 UTC 相同吗？
并不完全相同。Unix 时间基于 UTC，但刻意忽略闰秒，因此可能与真实 UTC 相差几秒。在应用开发的实际用途中，Unix 时间和 UTC 可以互换使用。这种区别只在科学、军事或高精度计时场景中才重要。Unix 时间始终以 UTC 为参考——它从不包含时区偏移或夏令时。
时区如何影响 Unix 时间戳？
时区不影响 Unix 时间戳——这正是它的意义所在。Unix 时间戳与时区无关，1710892800 在全球任何地方都代表同一个时刻。时区只在将 Unix 时间戳转换为人类可读格式时才会介入。在 JavaScript 中，new Date(1710892800 * 1000) 会根据浏览器的本地时区显示不同的时钟时间，但底层表示的时刻完全相同。始终以 UTC（Unix 时间戳的定义即为 UTC）存储和传输时间戳，仅在展示时才转换为本地时间。
Unix 时间与 ISO 8601 有什么区别？
Unix 时间是数值表示（一个计秒的整数），而 ISO 8601 是字符串格式（如 2024-03-20T00:00:00Z）。两者可以表示同一个时刻，但各有取舍。Unix 时间戳更紧凑（4—8 字节 vs 20 字节以上），比较更快（整数比较 vs 字符串解析），算术运算更简单；ISO 8601 字符串无需转换即可阅读，且自描述（包含时区信息）。API 通常同时接受两种格式；数据库可能存储其中一种而对外暴露另一种。存储和计算使用 Unix 时间戳，用户展示和注重可读性的数据交换使用 ISO 8601。
如何在 URL 参数中传递 Unix 时间戳？
将时间戳作为纯整数放在查询字符串中：https://example.com/api/events?since=1710892800。由于时间戳只包含数字，无需编码。服务端将其解析为整数并验证范围。常见验证项包括：确保值为正数（除非支持 1970 年前的日期）、不超过系统最大值，以及处于预期精度（秒级 vs 毫秒级）。如果 API 同时接收秒级和毫秒级时间戳，可通过位数判断：10 位为秒级，13 位为毫秒级。请在文档中说明 API 期望的精度，避免歧义。
总结
Unix 时间戳是软件工程的基础概念。其简洁性——从固定点起计秒的单个整数——使其成为跨语言、跨平台、跨时区存储、比较和传输时间值的理想选择。理解它的工作原理、应该使用哪种精度，以及要注意哪些陷阱（尤其是 2038 年问题），会让你成为更高效的开发者。
无论是在调试日志文件中的时间戳、设计数据库模式，还是构建服务多时区客户端的 API，Unix 时间戳都提供了可靠、无歧义的基础。将我们的 Unix 时间戳转换工具加入书签方便快速转换，记住：当不确定时，就用 64 位 Unix 时间戳以 UTC 存储时间。