整型时间：日志里那串数字，和屏幕上几点钟怎么对上号
从「整数秒/毫秒」与 UTC、本地时间的关系讲起，再说清 JSON、数据库、日志里几种常见精度混用会怎样；页内换算适合排雷而不是写底层库。
·
为什么工程师爱存整数：排序、差分、跨时区都省事
常见做法是从协调世界时的某个纪元起点开始数秒或数毫秒，把「时刻」压成单调递增的整数，比较先后、做范围查询都很直接。
展示给人看时，再把整数换回本 地时区的年月日时分秒；底层计数多在 UTC，表层显示才叠偏移。
秒和毫秒差三位：复制粘贴前先看字段注释
JSON 里可能是 10 位或 13 位；数据库里同一业务也可能混用 DATETIME 与 BIGINT。语言默认也不统一：有的 API 给浮点秒，有的给毫秒。
日志行里 ISO 8601 字符串与时间戳并列出现时，先确认哪一个是「真源」。
排障、对表、迁移：最常翻时间戳的三类活
读集中式日志、核对接口 `created_at`、做库表迁移前后比对同一事件；若日志来自海外机房，还要留心历史夏令时数据。
页内换算适合帮您省眼力和沟通成本
心算长整型容易把位数搞反；工具一键互转并给出人类可读时间，再截屏丢进工单，比口头报数稳。
和 时区换算 搭配，可以理解「同一事件在不同时区的表盘读数」。
典型线上事故长什么样
把毫秒当秒会回到纪元元年前后；把本地字符串当 UTC 解析，常见「全员差八小时」；审计和订单状态机会一起中招。
规范侧在推字符串 + 时区，存量整数还会躺很久
新接口更倾向 ISO 8601 带偏移；老系统、埋点、第三方 SDK 仍大量吐整型。换算页在过渡期会一直有用。
读完可以先做的一件事
从手头日志复制一条时间戳，在 Unix 时间戳换算 里分别按秒、毫秒各试一次，看哪种与日志文字对得上；延伸阅读见 时间戳指南 与 日志与时区误区。