Unix 时间戳

堆栈里 ts=1725446400，先数位数再对照 UTC 和 Asia/Shanghai。墙上的跨城会议走时区页。JWT 的 exp 先解码再拿数字来换。

支付回调、埋点、值班日志里的 ts=1725446400——纪元数字换成能读的钟。计算器 3000、365 工具箱一类中文文都把坑写在同一处：先分秒和毫秒，再叠加时区。时间戳不带时区，全球同一瞬间是同一个数。邮箱告警里只写当地时间、不写时区，对完日志才发现差了八小时，是另一类常见工单。

墙上的会走时区转换。班次长度走工时。日期间隔走日期间隔计算。Cron 预览按 UTC，在Cron 解析。JWT 解码看 exp，且不验签。

先数位数：10 位秒，13 位毫秒

• 不足约 12 位按秒乘 1000；更长按毫秒。16 位微秒、19 位纳秒请先截到秒，本页不保证。
• 选 Asia/Shanghai 看北京时间。全年加八小时是常量，因为大陆不再夏令时。
• 「现在」取自这只浏览器。系统时间错了，对照就错。
• 不是 GPS 时，不是取证钟，忽略闰秒。

对照北京时间，不是日历

1. 贴秒、毫秒，或点现在。先数位数。
2. 同时看 UTC、浏览器本地和你选的 IANA 区。
3. 年份离谱就检查秒毫秒是否贴反。跨城会议再去时区页，不要在本页硬排日程。

支付、物流接口常把 10 位秒写进回调；前端埋点又是 13 位。同一条工单里两套数字并排，先统一口径再对账。邮箱转发的 JSON 里只有 createTime，把数字拷到本页即可，不必整段日志都贴进来。

微信群里有人丢一串 13 位数字问「这是几点」，先数位数再选上海。不是订票，不是放假日历。输入过长会被截断，本页按短字符串处理。