先给结论：Unix 时间戳本身不带时区。它只是「从 1970-01-01 00:00:00 UTC 起经过了多少秒」。你看到的「差了 8 小时」，几乎都发生在把它翻译成人能读的字符串的那一步。
时间戳到底是什么
Unix 时间戳是一个整数，代表某个瞬间。它没有「北京时间」或「纽约时间」的概念——同一个瞬间，在任何地方取时间戳都是同一个数。正因为如此，数据库里存时间戳是最安全的：服务器搬家、系统时区被改，都不会让它变形。
唯一需要小心的是精度：10 位是秒，13 位是毫秒。把 13 位的毫秒值当秒来解析，会得到公元五万多年；反过来把 10 位秒值当毫秒，会落回 1970 年 1 月。这类错误在任何语言里都出现过。
差 8 小时的三个来源
一是存储与展示用了不同口径。 后端按 UTC 存，前端把它格式化成「本地时间」，看起来就对不上——其实两个都没错，只是没人说清各自用的是哪个时区。
二是服务器时区不是 UTC。 有的镜像默认 Asia/Shanghai，有的默认 UTC。同一段代码在两台机器上跑，写进日志的时间能差 8 小时。查日志对不上时间，先看 date 和 timedatectl。
三是字符串解析时被自动补了时区。 像 2026-10-19 00:00:00 这种不带时区的写法，浏览器和 Node 会按本地时区理解，而部分库会按 UTC 理解。同一条字符串，两种解释差 8 小时。
怎么快速自查
拿不准时做两个动作：① 把同一个时间戳分别按 UTC 和本地各读一遍，看两个结果是否相差整数小时；② 把「你以为的那个时间」换算成时间戳，和日志里的数值对比。差值 28800 秒就是 8 小时，说明是时区问题，不是逻辑问题。
三条能省掉大部分坑的习惯
- 存储一律用 UTC 时间戳，或带时区的 ISO 8601（如
2026-10-19T02:00:00Z） - 展示时显式指定时区，不要依赖运行环境的默认值
- 接口里传时间，永远带上时区，或明确声明「这是 UTC」
一句话总结
时间戳存 UTC，展示按用户时区，解析时显式带时区。 记住这三句，能挡掉绝大多数「时间对不上」的问题。
同一瞬间，五种写法
把「2026-10-19 02:00:00 UTC」这一天中的一个瞬间用五种方式写出来，差异出在哪就一目了然了：
1792375200—— Unix 秒。绝对，无歧义1792375200000—— Unix 毫秒。绝对，无歧义2026-10-19T02:00:00Z—— ISO 8601，末尾的 Z 表示 UTC。绝对2026-10-19T10:00:00+08:00—— ISO 8601，带显式偏移量。绝对2026-10-19 10:00:00—— 完全不带时区。它不是绝对时间，解析它的机器在哪个时区，它就指哪个瞬间
前四种在时间轴上指向同一个点，第五种在每台机器上指向不同的点。几乎所有「时间对不上」的争论，都源于把第五种当成前四种在用。
各家默认行为并不一样
这是最容易出问题的地方——同样叫「存一个时间」，不同技术栈的处理方式完全不同：
- MySQL：
TIMESTAMP会按连接时区把值转成 UTC 存储，读出来再转回连接时区；DATETIME原样存取，不做任何转换。字段类型选错，换个时区的客户端读到的值就变了 - PostgreSQL：
timestamptz存 UTC 且保留时区语义，timestamp不存时区。官方文档明确建议优先用前者 - Java：
Instant是绝对时间点，LocalDateTime没有时区。把LocalDateTime直接序列化成字符串传给前端，时区信息当场丢失 - Python：
datetime分 naive（无时区）和 aware（有时区）两类，两者相减会直接抛异常。用zoneinfo显式附加时区是现在的标准做法 - JavaScript：
Date内部永远是毫秒时间戳，但getHours()、toString()按运行环境时区输出，而toISOString()固定按 UTC 输出
共同规律只有一句：凡是叫「本地时间」的类型，都不携带时区信息，一旦跨机器传递就会失真。
时区别用缩写，用 IANA 名称
CST 这一个缩写能同时指中国标准时间（UTC+8）、美国中部时间（UTC−6）和古巴标准时间（UTC−5）。EST 也不安全，它不处理夏令时——美国东部在夏令时期间实际是 EDT（UTC−4），比 EST 早一小时。
正确做法是写 IANA 时区名，例如 Asia/Shanghai、America/New_York、Europe/Berlin。这类名称自带完整的夏令时规则，由系统时区数据库维护，跨年份都正确。
顺带一个容易被忽略的事实：中国在 1986 至 1991 年实行过夏令时，那几年的夏季实际是 UTC+9。如果系统要处理那个年代的历史数据，Asia/Shanghai 能算对，写死 UTC+8 就会差一小时。
排查时先问三个问题
- 这个值是绝对时间还是墙上时间？ 如果是时间戳，问题必然在展示环节；如果是字符串，先确认它是按哪个时区写下的
- 产生它、存储它、展示它的三方时区一致吗？ 不一致就必然存在换算，换算的代码就是嫌疑点
- 差值是不是整数小时？ 差 8 小时、差 5.5 小时（印度 UTC+5:30）都属于时区问题；差几秒、几十秒更可能是时钟同步或精度问题，跟时区无关
这三个问题能在读代码之前就砍掉一半可能性，比直接翻日志快得多。