速查在线工具箱日期与时间格式速查
ISO 8601 为什么是数据交换的首选、各国日期习惯差在哪、12 与 24 小时制怎么换算、格式化占位符怎么读。
日期看起来很直观，却是最容易出错的数据类型之一。同一个「03/04/2025」，在美国表示 3 月 4 日，在欧洲表示 4 月 3 日，中文里又要写成 2025 年 3 月 4 日。写错顺序在合同、报表和日志里都会造成实际误解。
解决这类歧义的标准答案是 ISO 8601：用「年-月-日」从大到小排列，加固定分隔符，这样无论谁读到都不会误判。理解它以及它与各国习惯的关系，就能把日期处理规范起来。
1ISO 8601 标准写法
ISO 8601 是国际通行的日期时间表示标准，核心思想是「从大到小排序」，并明确时区。它是数据交换与程序存储的首选格式。
| 场景 | 写法 | 示例 | 说明 |
|---|---|---|---|
| 仅日期 | YYYY-MM-DD | 2025-03-04 | 最常用，无歧义 |
| 仅时间 | hh:mm:ss | 14:30:00 | 24 小时制，补零 |
| 日期时间 | YYYY-MM-DDThh:mm:ss | 2025-03-04T14:30:00 | T 是日期与时间的分隔符 |
| 带时区偏移 | 末尾加 ±hh:mm 或 Z | 2025-03-04T14:30:00+08:00 | Z 表示 UTC 零时区 |
| 周历写法 | YYYY-Www-D | 2025-W10-2 | 第几周第几天，用于排期统计 |
| 纯 UTC 时刻 | 以 Z 结尾 | 2025-03-04T06:30:00Z | 与上例同一时刻，差 8 小时 |
| 基本格式 | 省略分隔符的紧凑写法 | 20250304T143000 | 少见，部分系统与文件名中使用 |
「`T` 分隔符 + 明确时区」是 ISO 8601 的两个关键设计。少了时区信息，同一个字符串在不同地区可能被解释成不同的绝对时刻。凡是要跨系统传递的时刻，都应带上时区，否则就是埋隐患。
2各国日期书写习惯
同一串数字在不同地区含义不同，这是日期处理里最大的坑。下表给出主要地区的习惯顺序。
| 地区 / 习惯 | 顺序 | 示例（2025 年 3 月 4 日） | 备注 |
|---|---|---|---|
| ISO 标准 | 年-月-日 | 2025-03-04 | 数据交换与文件命名首选 |
| 中国 | 年月日 | 2025 年 3 月 4 日 | 书面语用中文数字表达，数字形式常写作 2025-03-04 |
| 美国 | 月/日/年 | 3/4/2025 | 与多数地区相反，最易造成误解 |
| 欧洲多数国家 | 日/月/年 | 4/3/2025 | 同一串数字与美国含义不同 |
| 日韩 | 年月日 | 2025/03/04 | 顺序与中国一致 |
| 纯月年 | 月/年 | 03/2025 | 银行卡有效期常用，注意是月在前 |
| 年份简写 | 两位年 | 25 | 有世纪歧义，正式场合避免使用 |
遇到纯数字的 `03/04/2025` 时，最稳妥的做法是不要猜——直接问清或结合上下文判断。程序里如果必须解析这类字符串，应显式指定地区习惯，而不是依赖系统默认，否则同一份数据在不同服务器上可能解析出不同结果。
3常见格式化占位符
各语言与工具的占位符命名不统一，但含义基本对应。理解大写与小写的区别是关键。
| 含义 | 常见占位符 | 示例输出 | 注意 |
|---|---|---|---|
| 四位年 | yyyy / YYYY | 2025 | 用 yyyy 表示日历年更准确 |
| 两位月 | MM | 03 | 大写 MM 是月，小写 mm 通常是分钟 |
| 两位日 | dd | 04 | — |
| 两位时（24 制） | HH | 14 | 小写 hh 常指 12 小时制 |
| 两位分 | mm | 30 | 与「月」的大小写刚好相反，极易混淆 |
| 两位秒 | ss | 00 | SSS 通常是毫秒 |
| 星期 | EEEE / dddd | 星期二 / Tuesday | 语言环境不同输出不同 |
| 上下午 | a / A | 下午 / PM | 配合 12 小时制使用 |
| 时区名 | z / Z | GMT+8 / +0800 | Z 结尾专指 UTC |
「月」和「分」的占位符冲突是最经典的坑：多数格式里月是 `MM`、分是 `mm`，只差大小写，写反了不报错但结果完全错误。写格式化字符串时逐个字符核对，比事后排查容易得多。
412 小时制与 24 小时制的换算
12 小时制需要上下午标记，且 12 点的表示容易出错。换算规则其实很简单。
- 上午 12 点
- 12 小时制的 12:00 AM 等于 24 小时制的
00:00，即一天的开始 - 下午 12 点
- 12 小时制的 12:00 PM 等于 24 小时制的
12:00，即正午 - 上午换算
- 1:00 AM 到 11:59 AM 与 24 小时制数字相同，只是去掉 AM
- 下午换算
- 1:00 PM 到 11:59 PM 在 24 小时制上加 12，如
3:30 PM等于15:30 - 易错点
- 12 点前后最容易搞错：
00:30是凌晨，12:30是中午，相差 12 小时 - 跨地区
- 美英习惯用 12 小时制，中国与多数欧洲国家用 24 小时制，界面本地化时要考虑
5日期处理的实际注意点
- 存储与展示分离
- 数据库里存 UTC 时间戳或带时区的标准格式，展示时再按用户时区转换，避免存本地时间
- 文件命名用 ISO 格式
2025-03-04这种写法排序即时间顺序，文件列表天然按时间排好- 注意月末与闰年
- 直接给月份加一会遇到 1 月 31 日加一月的问题，应使用日期库做安全的加减
- 时区简称不可靠
CST在中国标准时间、美国中部时间等多个含义间歧义，应使用数字偏移或 IANA 时区名- 夏令时的影响
- 部分地区在夏令时切换时，某一天可能只有 23 小时或有重复的一小时
- 不要用字符串比较日期
- 格式不一致的日期字符串比较结果无意义，应先规范化再比较
看完就能用的站内工具
全部工具总览 →在线日期计算器：计算两日期相差天数与工作日、年/月/日精确分解；日期加减支持天/周/月/年及仅工作日推算；可查年龄（精确到岁/月/日）、生肖、星座，以及今天是第几周第几天
输入北京时间或UTC时间，快速换算全球主要城市时间，支持夏令时，纯浏览器本地计算
世界时钟 - 同时查看多个城市当前时间，跨国沟通必备
输入目标日期和事件名称，创建多个倒计时卡片，实时显示剩余天数/时/分/秒，支持本地存储
在线显示标准北京时间（UTC+8）与日期、星期、Unix 时间戳，并给出与您本机时间的时差，用于快速校时，纯浏览器本地处理
关于「日期与时间格式速查」的常见问题
为什么推荐用 ISO 8601 格式写日期？
因为它从设计上消除了歧义。它采用「年-月-日」从大到小的顺序，配合固定的分隔符，写出来的 2025-03-04 在任何国家、任何语言环境下都只有一个含义，不会像 03/04/2025 那样在美国读作 3 月 4 日、在欧洲读作 4 月 3 日。此外这个顺序还有一个附带好处：按字符串排序的结果就是按时间排序，所以它在文件命名、日志记录、数据交换中特别实用。时间部分它用 24 小时制并支持明确标注时区，进一步避免了上下午和跨时区的混淆。
12 小时制和 24 小时制怎么转换？
规则简单，但 12 点这个位置最容易错。上午部分（AM）：12:00 AM 对应 24 小时制的 00:00，是一天的开始；1:00 AM 到 11:59 AM 数字不变，直接去掉 AM 即可。下午部分（PM）：12:00 PM 对应 24 小时制的 12:00，是正午；1:00 PM 到 11:59 PM 需要加 12，比如 3:30 PM 等于 15:30。最常见的错误是把 12:00 AM 和 12:00 PM 搞反，以及忘记下午时段要加 12。换算时可以先判断是不是 12 点这个特例，其余按规则处理就不会错。
日期格式化里 yyyy-MM-dd 和 yyyy-mm-dd 有什么区别？
区别很大，而且写错常常不会报错，只会静默给出错误结果。在绝大多数格式化规则中，大写 MM 表示月份，而小写 mm 表示分钟，所以 yyyy-MM-dd 是正确的「年-月-日」，写成 yyyy-mm-dd 会输出分钟数代替月份。同样常见的还有小时：大写 HH 是 24 小时制，小写 hh 常指 12 小时制。这类大小写敏感的设计在各语言里基本一致，但正因为只差一个字母又不报错，是排查日期问题时最隐蔽的一类原因。写格式化字符串时建议逐字符核对，并在首次使用时用固定时间点测试输出。
跨时区的日期时间应该怎么存？
推荐统一存 UTC 时间，并以带时区的标准格式（如 ISO 8601 加时区偏移，或直接用 UTC 时间戳）保存，展示时再转换到用户所在时区。这样做的原因是：服务器可能分布在多个时区，用户也来自世界各地，如果直接存「本地时间」，就丢失了「这是哪个时区的时间」这个关键信息，后续换算与比较都会出错。另外要注意避免使用 CST、IST 这类时区简称，因为它们在多个国家有不同含义，容易产生歧义；应使用数字偏移（如 +08:00）或 IANA 时区标识（如 Asia/Shanghai）。如果业务涉及夏令时地区，还要注意切换当天可能出现 23 小时或有重复时刻的特殊情况。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。