时间戳与时区转换指南
时间戳转换是接口调试、日志排查、数据导入和跨时区沟通中的高频任务。最常见的问题不是工具不会转换，而是输入单位和时区口径不一致：Unix 秒与 Unix 毫秒相差 1000 倍，ISO 8601 可能带时区偏移，也可能被当作本地时间解析。使用时间戳转换器时，应先确认数据来源，再明确目标展示是 UTC 还是本地时区，并特别留意夏令时和边界日期。
适用场景
这篇教程适合在使用相关在线工具前快速确认处理方式、结果边界和常见误区。内容以日常办公、网页发布和开发调试为主，不替代法律、合规、安全或专业审计意见。
步骤
- 1
确认输入类型
先判断是 Unix 秒、Unix 毫秒还是 ISO 8601 字符串。
- 2
选择目标口径
明确要查看 UTC、本地时间，还是业务指定时区。
- 3
检查边界
对过期时间、跨日记录和夏令时日期进行单独复核。
- 4
保留原值
记录原始时间戳和转换结果，避免排查时丢失来源。
使用场景
时间戳转换适合排查接口字段、数据库记录、审计日志和定时任务。看到 `createdAt`、`expiresAt`、`iat`、`exp` 等字段时，先判断它是 Unix 秒、Unix 毫秒，还是 ISO 8601 字符串，再转换成人可读时间。对于 JWT、订单日志和前端埋点，单位错误会直接导致过期时间或排序判断偏差。
跨团队沟通时，建议同时写明 UTC 时间和业务所在地时间。只写“今天下午三点”容易在远程协作、服务器日志和用户本地时间之间产生误解。时间戳工具能帮助快速对齐，但最终记录仍应保留原始值。
Unix 秒、Unix 毫秒与 ISO 8601
Unix 时间戳表示从协调世界时 1970-01-01 00:00:00 开始经过的时间。Unix 秒通常是 10 位左右，Unix 毫秒通常是 13 位左右。把毫秒当秒会得到很遥远的未来时间，把秒当毫秒会得到 1970 年附近的时间，这是最常见的单位错误。
ISO 8601 是可读性更强的日期时间格式，例如带 `Z` 表示 UTC，带 `+08:00` 表示相对 UTC 的偏移。没有时区标记的日期字符串可能被环境按本地时间解释，因此在接口和文档中应尽量写完整时区信息。
UTC、本地时区与夏令时
UTC 是统一参考，不随地区变化。本地时区则取决于用户设备、浏览器和操作系统设置。服务器日志常用 UTC，业务报表常用本地时区，前端页面可能按用户当前位置显示。排查问题时，先确认每一层使用的时区，再比较时间差。
夏令时会让某些地区在一年中出现小时跳变或重复。某一天可能少一个小时，也可能同一个本地时间出现两次。处理预约、账单、定时任务和日志窗口时，不应只按固定 24 小时推断所有本地日期。
常见错误
常见错误包括秒和毫秒混用、忽略字符串末尾的 `Z`、把本地时间当 UTC、在夏令时切换日按普通日期处理，以及复制时间戳时漏掉最后三位。还有一种问题是 Excel 或表格工具把长数字转成科学计数法，导致原始值被改写。
排查时建议保留原始输入、转换结果和目标时区。对于 JSON 数据，可先用 JSON 格式化工具查看字段，再把单个时间值放入时间戳转换器，不要在不明确单位时批量改写数据。
注意事项
时间戳转换器适合做格式理解和人工排查，不应替代系统内部严格的时间处理库。涉及账单、合约、定时任务或审计记录时，应使用系统约定的时区策略，并由业务规则决定边界日期。
本站时间戳转换在当前浏览器中完成，不上传输入数据。工具不会判断某个时间在业务上是否有效，也不会替代安全、合规或审计结论。
常见问题
怎么判断是 Unix 秒还是毫秒？
通常 10 位左右更可能是秒，13 位左右更可能是毫秒，但仍应以接口文档或字段说明为准。
UTC 和本地时间哪个更适合记录？
系统记录通常优先使用 UTC，展示给用户时再转换到本地或业务指定时区。
为什么转换后时间差了几个小时？
多半是 UTC、本地时区或时区偏移理解不一致，也可能与夏令时有关。
时间戳工具会上传数据吗？
不会。转换在当前浏览器中完成，输入不会发送到服务器。
相关推荐
继续阅读与当前任务相邻的工具教程，避免重复设置和口径误判。