开发者工具·Unix时间戳转换器
秒还是毫秒？区分 10 位纪元和 13 位纪元
· 工作原理
时间戳 Unix 时间 开发人员工作流程
您今天遇到的大多数纪元值要么是十位数字（秒），要么是十三位数字（毫秒），猜错了会导致日期落后数万年。这篇文章解释了数字计数背后的算术，以及为什么转换器应该声明单位而不是推断单位。
1700000000 还是 1700000000000？ —同一时刻有两种写法，仪表板显示遥远未来的日期
日志值 1700000000 和负载值 1700000000000 可以描述同一时刻。将第一个视为毫秒，您的仪表板将落入 1970 年 1 月；将秒视为秒，其日期会跳转到数千年后的未来。时间戳只是一个计数加上一个单位和起点，因此没有文档的名为created_at的数据库列省略了重要信息。
为什么当前的秒数有十位数——2001 年是十亿秒，十位数范围一直到 2286，以及九位数意味着什么
Unix 时间按照通常的 POSIX 约定计算从 1970-01-01 00:00:00 UTC 起经过的秒数。 2001年，该数字突破10亿大关；对于当代的正日期，它通常是十位小数。它保持十位数字，直到 2286 年达到 100 亿。这是十进制表示法的属性，而不是 ISO 日期字符串中的规则。纪元之前的负值和远远超出当前的日期会使简单的数字计数快捷方式无效。
为什么毫秒计数有 13 — 一千的因数、三位额外数字，以及 JavaScript 和 Java 约定的来源
JavaScript Date.getTime() 按照惯例计算毫秒，将秒时间戳乘以 1,000。三个零使当前的十位数秒计数变成十三位数毫秒计数。例如 1,700,000,000 秒变为 1,700,000,000,000 毫秒；均为 2023-11-14T22:13:20.000Z。仅插入分隔符而不说明假定单位的转换器可能会将有效数字转换为看似合理但错误的日期。
猜测出错的地方 — 纪元附近的小值、2001 年之前的日期以及数字计数不再区分的未来日期
在 1970 年左右，当毫秒值可能很短时，启发式方法会失败；在 2001 年之前，当秒数少于十位数时，或者使用微秒和纳秒计数器时，启发式方法会失败。 ToolAcre 默认将低于 10^1 的数值解释为秒，将更大的值解释为毫秒，并标记所使用的单位。该阈值是实际的猜测，而不是明确的格式解码器。特定 API 提供的时间戳应使用该 API 的文档进行解释，即使其长度不常见。
工作示例：一个日志中的三个值 — 1700000000、1700000000000 和 1700000000000000，以秒、毫秒和微秒为单位读取
说明性日志中的三个整数显示了该陷阱。将 1700000000 解释为秒，将 1700000000000 解释为毫秒：两者都解析为 2023-11-14T22:13:20Z。将 1700000000000000 解释为微秒并除以一百万以获得相同的秒数。 ToolAcre 转换器接受秒或毫秒，而不是微秒模式：粘贴第三个数字而不先转换其单位将无法确认预期的时刻。调试时始终将原始字段及其单元放在一起。
为什么应该说明单位，而不是猜测单位 - 转换器如何显示它所应用的单位，以便错误的假设是可见的而不是沉默的
发送时间戳的服务应在其架构中命名该单元或使用带有显式偏移量的 ISO 8601 文本。如果遗留字段未记录，请在做出决定之前将多个值与另一个可靠事件时间进行比较；单一的巧合可信日期不足以作为证据。转换器会显示它所应用的单位，让您有机会发现 1,000 倍的错误。明确更改单位并进行比较，而不是依赖自动猜测作为长期 API 合约。
这不包括 - 以字符串形式存储的时间戳、ISO 8601 文本或电子表格序列日期，这是不同的问题
本文不解释 Excel 序列日期、2026-09-28T10:15Z 等字符串或本地时钟读数的时区格式。这些是不同的表示。 Unix时间戳指的是一个瞬间；同一时刻在不同区域显示为不同的挂钟时间。闰秒约定也值得单独处理，并且 32 位有符号计数器在 2038 年存在溢出问题，这与秒与毫秒的问题不同。
要点：计算数字，然后确认单位——以及 Unix 时间戳转换器如何读取带有单位标记的秒和毫秒
计算数字作为初始提示，然后确认生产者规定的单位和至少一个已知事件。 Unix 时间戳转换器使应用的秒/毫秒假设可见，并在浏览器中打印 UTC 和本地表示形式。不要让看起来整洁的日期覆盖产生该值的系统中相反的文档。