数字与格式化日期
Unix 时间戳紧凑且便于计算；ISO 8601 可读，并能声明 UTC 偏移。2023-11-14T22:13:20Z 中的 Z 表示 UTC，对应 Unix 时间戳 1700000000 秒。
保持同一时刻
2023-11-14T22:13:20Z 与 2023-11-15T06:13:20+08:00 描述同一时刻，转换为 Unix 时间后得到相同数值。若 ISO 字符串没有 Z 或偏移，就必须由外部规则说明它属于哪个时区。
往返转换的选择
面向人工查看的日志和数据交换，适合使用带明确偏移的 ISO 字符串；需要紧凑存储和算术处理时，可使用明确记录单位的 Unix 数值。源数据包含有效小数秒时，应在往返过程中保留精度。
ISO 8601 与 RFC 3339
RFC 3339 是面向互联网时间戳的更受限格式子集。实际 API 中应查看字段规范，不要仅凭字符串外观猜测是否允许省略偏移或采用不常见日期形式。
带偏移日期与 Unix 时间如何对应？
| 表示方式 | 同一时刻的值 |
|---|---|
| UTC | 2023-11-14T22:13:20Z |
| 北京偏移 | 2023-11-15T06:13:20+08:00 |
| 纽约偏移 | 2023-11-14T17:13:20-05:00 |
| Unix 秒 | 1700000000 |
末尾的 Z 表示 UTC 零偏移；带正负号的偏移说明显示钟点与 UTC 相差多少。去掉偏移后，日期就需要一个来源时区才能确定具体时刻。把北京钟点直接加上 Z 是宣称它为 UTC，会改变含义，并没有完成换算。
按步骤核对往返转换
在时间戳转换器输入 1700000000，选择秒，复制 ISO 输出。再到日期转时间戳，输入 2023 年 11 月 14 日 22:13:20、选择 UTC 和秒，结果应回到同一个整数。
2023-11-14T22:13:20.123Z 对应 1700000000123 毫秒。如果目标系统只支持整数秒，123 毫秒就无法保留。交换数据前应确认双方允许的精度，而不是只核对日期格式。
哪种格式适合接口？
ISO 8601 包含的形式比许多程序解析器支持的更多。RFC 3339 是面向互联网交换的较窄格式约定；扩展日期、钟点和明确偏移通常更便于兼容。
[America/New_York] 后缀附带 IANA 时区标识，但不是所有 ISO 或 RFC 3339 解析器都接受。普通接口优先使用 UTC ISO 输出，涉及地区规则的排程另存时区名称。不要把 03/04/2026 这种日期顺序不明确的字符串写进接口；缺少偏移的日期应参照时区与夏令时指南解释。