接口时间字段不对：10 位、13 位时间戳和时区怎么查
围绕接口、日志和表格里的时间字段，讲清 10 位秒级、13 位毫秒级、时区偏移、前后端显示不一致该怎么定位。
相关工具
时间不对，先看数字位数
接口时间字段最常见的问题是单位搞错。10 位通常是秒级时间戳，13 位通常是毫秒级时间戳。如果把 13 位毫秒当成秒，时间会跑到很遥远的未来；如果把 10 位秒当成毫秒，时间会回到 1970 年附近。看到时间异常时，先不要急着改格式，先把原始值复制到时间戳工具里验证。
字段名也能提供线索。createdAt、updatedAt 不一定说明单位；createdAtMs、timestampMillis 更可能是毫秒；expireSeconds、ttl 可能表示秒数而不是绝对时间。接口文档如果没有写清楚，就用多条数据对比，看它们是否接近当前时间。
时区问题通常差 8 小时
如果时间整体差 8 小时，优先怀疑 UTC 和北京时间转换。后端日志可能用 UTC，前端展示用本地时区，数据库存储又是另一套规则。不要只看格式化后的字符串，最好保留原始时间戳、时区信息和展示结果三者一起排查。
JavaScript 里可以这样快速看本地时间和 ISO 时间：
const ts = 1720953600000
const date = new Date(ts)
console.log(date.toISOString())
console.log(date.toLocaleString("zh-CN", { timeZone: "Asia/Shanghai" }))toISOString 输出 UTC 时间，toLocaleString 可以按指定时区展示。两者不同是正常的，关键是你的业务到底要展示哪一个。
日期字符串也可能有坑
接口有时返回 2026-07-15 10:30:00 这种字符串，看起来清楚，但缺少时区信息。不同语言、不同浏览器解析它时可能有差异。更稳的做法是接口统一返回时间戳或带时区的 ISO 字符串，比如 2026-07-15T02:30:00Z 或 2026-07-15T10:30:00+08:00。
如果你要把 CSV、Excel 或日志里的时间导入系统，先抽几条样例转换验证。尤其是跨地区业务、服务器在海外、用户在国内时，时间字段要提前定规则。否则统计报表、订单过期、会员到期都可能出现边界问题。
排查时保留原始值
不要在清洗数据时直接覆盖原始时间字段。更好的做法是新增一个可读字段，比如 created_at_text，同时保留 created_at_timestamp。后面如果发现单位或时区规则错了，还能从原始值重新计算。这个习惯在批量数据处理里非常重要。
接口联调时，也建议把请求时间、服务端接收时间、响应时间一起记录。很多“时间错了”的问题，其实是缓存、延迟、队列或前端本地时间不准造成的。先把时间链路记录完整，再判断谁的转换规则错。
常见问题
10 位时间戳和 13 位时间戳有什么区别？
10 位通常是秒，13 位通常是毫秒。转换前先确认单位。
为什么时间差 8 小时？
大概率是 UTC 和北京时间的展示差异，要检查存储、接口和前端展示时区。
接口应该返回字符串还是时间戳？
都可以，但要统一规则。建议返回明确单位的时间戳或带时区的 ISO 字符串。