时间的格式
时间在程序里从来不是”直接写个日期”那么简单。同一个时刻，不同的人看到的时间可能完全不一样——你在上海下午三点发出一条消息，朋友在纽约打开电脑，看到的是凌晨两点。时间格式和时区的处理，是每个开发者迟早都要面对的坑。
这篇文章不讲太深的理论，用 Java 举例，把日常开发里最常见的时间格式和时区概念说清楚。
常见时间字符串格式
ISO 8601 — 最通用的标准
现在几乎所有 API 都推荐用 ISO 8601 格式传时间。一条典型的 ISO 8601 时间长这样：
2026-06-18T15:30:00+08:00拆开看：
2026-06-18— 日期，年-月-日T— 分隔符，表示后面是时间部分15:30:00— 时间，时:分:秒+08:00— 时区偏移，表示比 UTC 快 8 小时
如果时间用的是 UTC，末尾写成 Z（Zulu time，零时区的代号）：
2026-06-18T07:30:00ZZ 就是 +00:00 的简写。
Unix 时间戳
另一种常见格式是 Unix 时间戳——从 1970-01-01 00:00:00 UTC 到现在的秒数：
1770723000Unix 时间戳没有时区的概念，因为它在全世界任何地方都代表同一个时刻。后端存储常用时间戳，前端再根据用户时区转成当地时间。
Java 里怎么处理时间和时区
Java 8 之前的时间 API（java.util.Date、SimpleDateFormat）设计有问题，不建议再用。Java 8 引入了 java.time 包，下面几个类最常用：
LocalDateTime — 不带时区的本地时间
LocalDateTime now = LocalDateTime.now();
// 2026-06-18T15:30:00
// 只表示"当前本地时间"，不知道这是哪个时区LocalDateTime 没有时区信息，适合做”倒计时”、”营业时间”这种跟时区无关的场景。
ZonedDateTime — 带时区的完整时间
ZonedDateTime shanghai = ZonedDateTime.now(ZoneId.of("Asia/Shanghai"));
// 2026-06-18T15:30:00+08:00[Asia/Shanghai]这个就是完整的带时区时间了。方括号里 Asia/Shanghai 是时区 ID，+08:00 是偏移量。
OffsetDateTime — 只带偏移量
OffsetDateTime now = OffsetDateTime.now();
// 2026-06-18T07:30:00Z
// 或者 2026-06-18T15:30:00+08:00跟 ZonedDateTime 的区别是它不关心”这个偏移属于哪个地区”，只告诉你偏移了多少小时。
Instant — 时间戳的 Java 版本
Instant now = Instant.now();
// 2026-06-18T07:30:00Z
// 始终是 UTC，适合后端存储和传输时区的标识
时区标识在编程里主要有两种写法：
1. 地区/城市 格式（推荐）
Asia/Shanghai
America/New_York
Europe/London
Asia/Tokyo这是 IANA 时区数据库的标准格式。优点是自动处理夏令时（DST）。比如 America/New_York 在夏令时是 UTC-4，冬令时变成 UTC-5，Java 拿到这个 ID 会自动切换。
2. 偏移量格式
+08:00
-05:00
+00:00只告诉你”比 UTC 快/慢多少小时”，不告诉你这个地区有没有夏令时。如果你存的只是偏移量，等到夏令时切换那天就会出问题。
上海时间 +8 到底是什么意思
“上海时间 +8” 其实是说 上海所在的时区是 UTC+8，也就是比世界协调时（UTC）快 8 个小时。
举个例子：
UTC 时间 2026-06-18 07:30
上海在这个时刻已经是 2026-06-18 15:30（07:30 + 8 小时）。
在 Java 里对应：
- 时区 ID：
Asia/Shanghai - 偏移量：
+08:00 - 和北京时间完全一致（中国全国用一个时区）
要注意的一点是：中国虽然没有夏令时，但 Asia/Shanghai 这个时区 ID 在 IANA 数据库的历史记录里其实包含过夏令时的数据（民国时期和建国初期有过短暂调整）。你用 +08:00 做简单场景没问题，但如果要做严谨的历史时间计算，建议用 Asia/Shanghai 而不是硬编码偏移量。
日常开发里怎么选
- 数据库存时间 → 用
Instant（UTC）或者带时区的时间类型（TIMESTAMP WITH TIME ZONE） - API 传参 → 用 ISO 8601 字符串，末尾带
Z或偏移量 - 展示给用户 → 后端传 UTC 时间或时间戳，前端根据浏览器时区转成当地时间
- 定时任务 → 指定时区 ID（比如
Asia/Shanghai），不要用偏移量 - 日志记录 → 一律用 UTC + ISO 8601，排查问题时换算方便
容易踩的坑
- Date.toString() 输出的时区不是你想要的： Java 的
java.util.Date底层存的其实是 UTC 时间戳，但toString()用 JVM 默认时区展示，容易误解 - SimpleDateFormat 线程不安全： 多线程环境下用
DateTimeFormatter（Java 8+）代替 - 偏移量和时区 ID 混用：
+08:00不等于Asia/Shanghai，前者没有夏令时信息，遇到有夏令时的地区会出 bug - 不要用三个字母的时区缩写（CST、PST）： CST 既可以是 China Standard Time，也可以是 Central Standard Time（美国中部），歧义太多
总结
时间格式和时区看起来是基础概念，但实际项目里因为这个出 bug 的场景一点都不少。核心记住几点：
- 用 ISO 8601 格式传时间
- 后端存 UTC，前端展示本地时间
- 时区用 IANA ID（Asia/Shanghai），别用偏移量硬编码
- “上海时间 +8” 就是 UTC+08:00，比世界协调时快 8 小时