日期、时间与计划

日志中的 10 位或 13 位时间戳是哪一天？

使用工具

日期错误常从单位不明开始：把秒当毫秒，或 UTC 与当地钟表时间比较。正确数字也会得到奇怪日期。不要先加减偏移凑结果，应分开单位和显示规则。

Unix 时间以明确选择的单位读取整数时间戳，显示 UTC 与选定时区，不按位数自动决定。先从 0 开始，再用已知日期重现秒毫秒混淆。

输入 0 秒，显示时区 Asia/Tokyo

UTC:        1970-01-01T00:00:00Z
Asia/Tokyo: 1970-01-01T09:00:00+09:00

两者是同一瞬间，东京显示无需给 Unix 值加九小时。换时区是换钟表读同一瞬间，再加九小时就同时改变瞬间，重复调整了。

只写 2024-01-01 09:00 的日志缺时区，无法分辨 UTC 九点还是东京九点。分享时应带 Z、+09:00 等偏移或时区名，便于重现同一瞬间。

相同数字只改单位

1704067200 seconds      → 2024-01-01T00:00:00Z
1704067200 milliseconds → 1970-01-20T17:21:07.2Z

按秒是 2024 元旦，按毫秒是 1970 年一月。同一瞬间毫秒值为 1704067200000，相差一千倍。不要试着增删位数，应先查生成方单位。

十位秒、十三位毫秒只是常见年代的经验，靠近 1970、负值或远期日期位数不同。字段叫 timestamp 也不能确定单位，API 或存储约定应明写。

表示同一瞬间的两个输入

2024-01-01T00:00:00Z
2024-01-01T09:00:00+09:00

分别反向转换，按秒都得到 1704067200，说明是显示区别而非瞬间偏移。无偏移日期可能依赖环境解释，不宜用于可复现实验。

含小数秒时，应区分整数秒字段与选定单位的结果。把毫秒日志降为整数秒会丢掉同秒内顺序，应先定精度并检查是否截位。

2024-01-01 没有钟表时间和时区，转瞬间需额外约定。为方便把生日或营业日变 UTC 零点，其他地区可能显示前一天。纯日期应按用途保留日期语义。

问日期间几天用暦日差，问瞬间间几秒用经过时间。日历一天不总是二十四小时，尤其时区转换附近，应先明确问题再选输入形式。

服务器日志相差几秒，统一单位时区后也可能仍存在。工具只转换时间值，不测时钟同步或网络延迟。还应查记录的是开始、结束、客户端还是接收时刻。

能转换不证明对应正确事件。检查是否复制错列或生成规范变化。选一个已知事件，对照值、单位、UTC 与当地显示以定位层次。

不要只报 1704067200，应写 Unix 秒及 UTC 对应值，必要时附 Asia/Tokyo。缺单位或时区会迫使接收者猜测，复制结果时保留标签。

保留 0、已知日期、秒毫秒同一瞬间和带偏移反向转换的固定测试。只用当前时间每次结果都变，固定例更容易发现单位混淆和重复时差调整。

2024-01-01T09:00:00+09:00 与 2024-01-01T00:00:00Z 是同一瞬间，Unix 秒均为 1704067200。转换可避免把时差当延迟。但只有秒精度的日志不能判定同秒事件先后，乘成毫秒只是加零，不会增加原本缺失的细节。

设备时钟偏差也可能使正确转换后的排序与实际相反，应结合请求 ID 和处理关系，不能只靠时间转换断定因果。记录原值、秒或毫秒、显示时区和日志精度，将表示统一、时钟同步、事件顺序三个确认步骤分开。