UNIX 时间戳将时间点表示为自 UNIX 纪元以来经过的时间。它不存储命名时区、夏令时规则或日历名称。面向人员或地点显示时间点时，系统才会添加这些规则。
快速回答： 请先确定单位。当前的十位数通常表示秒。当前的十三位数通常表示毫秒。请将值转换为时间点，然后以 UTC 或命名的 IANA 时区格式化。绝不要将固定 UTC 偏移量当作完整时区。
本用例介绍纪元单位、负值、UTC、偏移量、季节性转换、ISO 8601 文本、JavaScript 限制和 Windows 文件时间转换。这些概念连接到 UNIX 时间戳转换器和日期、时间和时间戳集合。
什么是 UNIX 时间戳？
UNIX 纪元从 1970-01-01 00:00:00 UTC 开始。UNIX 时间戳通常计算自该参考时间点以来不含闰秒的秒数。正值表示之后的时间点。如果系统支持，负值表示更早的时间点。
POSIX 时间模型定义了自纪元起的秒数和日历转换规则。RFC 9636 将 UNIX 时间定义为自 POSIX 纪元起不含闰秒的整数秒。实现和语言可能强制使用更窄范围或不同数值精度。
时间戳不等于显示日期。一个时间点可以在东京、加尔各答、伦敦和纽约显示为不同的本地日期。时间戳不会变化。表示形式会因每个地点应用自己的时区规则而变化。
| 值类型 | 示例 | 含义 | 主要风险 |
|---|---|---|---|
| UNIX 秒 | 1725148800 |
自纪元以来的秒数 | 与毫秒混淆 |
| UNIX 毫秒 | 1725148800000 |
自纪元以来的毫秒数 | 与秒混淆 |
带 Z 的 ISO 日期 |
2024-09-01T00:00:00Z |
UTC 时间点 | 解析时丢失 Z |
| 带偏移量的 ISO 日期 | 2024-09-01T05:30:00+05:30 |
时间点和数字偏移量 | 将偏移量当作命名时区 |
| 本地日期 | 2024-09-01 05:30 |
没有明确时间点的日历字段 | 缺少时区和重叠选择 |
UNIX 时间戳取决于时区吗？
不取决于。有效 UNIX 时间戳会独立于显示时区标识一个时间点。时区会影响该时间点与本地日历字段之间的转换。
直接回答： 不要加减本地 UTC 偏移量来“转换” UNIX 值的时区。请保留时间点，让时区库使用目标时区格式化它。
当地点改变偏移量时，手动计算偏移量会失败。夏令时可能造成季节性变化。政府可能修改民用规则。历史偏移量可能不同于当前偏移量。有些地区使用非整小时偏移量。
IANA 时区数据库记录代表性地点的当前和历史民用规则。规则改变时，系统会更新该数据库。America/New_York包含规则历史。-05:00只包含数字偏移量。
如何区分秒和毫秒？
没有适用于每个日期的数字位数规则。对于当前数据，数量级可以提供实用线索，但不是正式类型系统。可靠界面应要求单位，或显示推导出的单位。
接近当前时间时，UNIX 秒通常约有十位数字。毫秒通常约有十三位。微秒和纳秒使用更大的值。未来日期、负日期、前导零、小数值和字符串都可能使长度测试失效。
请使用以下安全流程：
- 阅读源系统文档。
- 在确定单位和数值范围前，将值作为文本保留。
- 明确选择秒、毫秒、微秒或纳秒。
- 精度重要时，使用整数库。
- 将结果年份与预期业务范围比较。
- 显示预期的 UTC 和命名时区。
如果 1725148800 生成 1970 年 1 月的日期，转换器可能将秒当作毫秒。如果 1725148800000 生成几千年后的日期，转换器可能将毫秒当作秒。合理的年份有助于检查，但源文档仍然是权威依据。
为什么 JavaScript 可能丢失时间精度？
JavaScript Number 使用 IEEE 754 二进制浮点值。它只在定义的安全范围内精确表示整数。当前日期附近的毫秒可以正常表示，但纳秒不能。
ECMAScript Date 以毫秒存储时间值。ECMAScript 日期规范定义了值和允许范围。实现会拒绝范围外的值。解析还取决于输入语法和已有时区。
对于微秒或纳秒，请使用 BigInt 或合适的库。在检查范围前，不要将大整数字符串转换为 Number。转换可能静默舍入低位数字，并改变时间点。
API 返回时间戳时，请在字段名或模式中记录单位。createdAtEpochSeconds比timestamp更安全。JSON 除了语法外不区分整数大小。生产者和消费者需要一个契约。
UTC、偏移量和命名时区有什么区别？
UTC 是全球时间点使用的共同时间标准。UTC 偏移量表示某一时间点的本地时间与 UTC 之间的差异。命名时区提供根据日期确定偏移量的规则。
| 术语 | 示例 | 会随日期变化 | 单独标识时间点 |
|---|---|---|---|
| UTC 标记 | Z |
否 | 是，需要日期和时间 |
| 数字偏移量 | +05:30 |
该值不会变化 | 是，需要日期和时间 |
| IANA 时区 | Asia/Kolkata |
可能变化 | 否，缺少本地日期和时间 |
| 本地墙上时间 | 2026-11-01 01:30 |
不适用 | 否 |
在回拨期间，命名时区可能将一个本地时间映射到两个时间点。在跳拨期间，它可能无法映射。库会将这些情况称为重叠和间隙。应用需要一个解析规则。
对于计划事件，请存储预期语义。一次性会议可以存储时间点和显示时区。要保持本地 09:00 的重复事件，可能需要本地时间、命名时区、重复规则和数据库更改时的行为。只存储第一个时间点可能使未来事件发生偏移。
夏令时转换会发生什么？
春季转换时，时钟可能向前跳。本地时间间隔可能不存在。秋季转换时，时钟可能向后跳。本地时间间隔可能使用不同偏移量出现两次。
假设本地时钟两次显示 01:30。只有本地日期和时间的字符串无法确定用户指的是哪个时间点。请加入数字偏移量，或使用命名时区库和明确的早前或晚后规则。
ECMAScript 提案 Temporal 对这些差异进行建模。ZonedDateTime 文档解释精确时间、时区和日历。它还说明间隙和重叠的解析行为。依赖提议接口前，请检查支持情况和生产状态。
不要无限期缓存时区偏移量。请更新提供 IANA 数据的环境或数据库。保持服务器、客户端、容器和数据库镜像为最新。过时数据可能让两个服务为同一未来事件计算不同本地时间。
应如何格式化时间点？
请使用带明确 UTC 标记或偏移量的机器可读格式。RFC 3339 定义了常用的互联网日期时间配置文件。RFC 3339 规范定义完整日期、完整时间、偏移量和可选小数。
示例：
2026-09-01T12:00:00Z表示 UTC 中午。2026-09-01T17:30:00+05:30表示带偏移量的同一时间点。2026-09-01T12:00:00.123Z增加毫秒精度。2026-09-01 12:00:00没有说明时区或偏移量。
互操作性重要时，请使用大写 T 和 Z。保留需要的小数精度。不要添加没有意义的数字。秒级来源不会因为添加九个零而获得纳秒精度。
对于带命名时区的新协议，请检查 RFC 9557的扩展格式。它在 RFC-3339 时间戳中使用方括号添加包括时区名称在内的信息。引入前请确认所有消费者都支持该格式。
闰秒如何影响 UNIX 时间？
UTC 偶尔包含闰秒。常见 UNIX 和 POSIX 表示不会通过简单连续映射，为每个闰秒标签分配唯一的普通时间戳。系统可能忽略、重复、平滑该事件，或使用特殊时钟处理。
IANA tz 项目在其理论时区文件中记录决策和限制。时间库通常面向民用时间戳，而不是科学高精度测量。
应用处理金融序列、卫星数据、分布式日志或科学测量时，请定义时间尺度。UTC、TAI、GPS 时间、单调时钟和系统时钟解决不同问题。浏览器转换器不应成为精确时间的权威。
请使用单调时钟测量进程内的持续时间。民用时钟可能因同步、管理或虚拟机而改变。请为审计存储事件时间点。使用平台的单调接口测量代码持续时间。
如何安全转换 UNIX 时间戳？
请遵循以下流程：
- 确定源系统和单位。
- 保留原始值以供审计和诊断。
- 验证语法、符号、范围和允许精度。
- 将值转换为时间点，不要手动应用本地偏移量。
- 将时间点格式化为稳定的 UTC 引用。
- 将相同时间点格式化为请求的 IANA 时区。
- 显示该日期使用的数字偏移量。
- 将年份和本地上下文与预期值比较。
UNIX 时间戳转换器提供针对性的转换流程。请从样例数据开始。浏览器工具有助于检查值。源 API 契约决定正确单位。
对于批量或生产转换，请使用维护良好的库。锁定并更新其时区数据。为间隙和重叠、年份变化、负值、小数和允许的最大值添加测试。
Windows 文件时间有什么区别？
Windows 文件时间和 UNIX 时间使用不同纪元和单位。FILETIME通常表示自1601-01-01 UTC以来的 100 纳秒间隔。UNIX 时间通常表示自1970-01-01 UTC以来的秒数。
转换需要纪元偏移量和单位系数。FILETIME可能超过 JavaScript 安全范围，因此大整数运算很重要。通过 Number 转换可能丢失最后的数字。
请使用 UNIX 到 Windows 文件时间工具执行受控转换。反向转换请使用 Windows 文件时间到 UNIX 工具。将原始整数保留为文本。如果取证精度重要，请使用另一个实现检查结果。
Windows 文件时间文档介绍 100 纳秒间隔。文件系统可能使用不同精度、更新时间或本地转换。名义单位不能证明源数据使用了该精度测量。
数据库和 API 建议
请使用与模型匹配的类型。带时区的数据库时间戳可以规范化时间点，但每个供应商的语义不同。不带时区的时间戳可以表示本地字段。设计迁移前请阅读文档。
对于 API 事件，请发送带 Z 的 RFC-3339 字符串，或发送带明确单位的有文档整数。避免无文档值。如果命名时区具有业务意义，请单独传递它。
对于未来事件，如果必须保持本地时间，请存储多个字段。有用的记录可能包含：
- 本地日期和时间；
- IANA 时区标识；
- 重复规则；
- 解析决定；
- 原始用户输入；
- 下一个计算的时间点；
- 规则更新策略。
对于过去的事件日志，请存储时间点和有用上下文。偏移量有助于显示和诊断。命名时区可能仍然有助于人工解释。
时间戳常见错误
错误 1：只根据数字猜测单位
数字位数只是线索，不是契约。请确认源单位和预期范围。
错误 2：添加偏移量来改变时区
此操作会改变时间点。请保留时间点，并在目标时区中格式化。
错误 3：将缩写用作时区
CST等缩写可能表示多个地点或偏移量。请使用 IANA 标识或有文档的数字偏移量。
错误 4：解析不带时区的日期和时间
解析器可能采用设备时区、UTC 或其他规则。时间点应要求明确偏移量。本地计划应使用命名时区建模。
错误 5：忽略季节性间隙和重叠
有些本地时间不存在，或会出现两次。请加入测试用例和解析规则。
错误 6：使用浮点数转换大时间戳
微秒、纳秒和 FILETIME 的整数可能丢失精度。请将它们保留为字符串或任意精度整数。
错误 7：将客户端时钟用于安全判断
设备时钟可能错误或被篡改。安全协议需要服务器检查、过期容差、重放保护和可靠时间源。
检查清单
接受转换前，请回答以下问题：
| 检查 | 原因 |
|---|---|
| 源使用什么单位？ | 1,000 倍系数错误会生成错误日期 |
| 输入是整数还是小数？ | 小数部分可能改变精度 |
| 值可能为负吗？ | 某些系统拒绝纪元前日期 |
| 数值类型会保留该值吗？ | 舍入可能改变低位单位 |
| 输出使用 UTC 还是命名时区？ | 本地名称需要规则 |
| 本地时间只出现一次吗？ | 季节性时间会产生间隙和重叠 |
| 使用哪个数据库版本？ | 未来民用规则可能改变 |
| 源测量了什么精度？ | 保存的数字可能夸大精度 |
此清单可以将含义不明的数字变成有文档的转换。它也可以改善错误报告。请加入原始值、单位、预期时间点、目标时区、环境和时区数据版本。
常见问题
UNIX 时间总是使用秒吗？
传统表示使用秒。许多 API 使用毫秒、微秒或纳秒，并将字段称为 UNIX 时间。请阅读模式和单位。
UNIX 时间包含时区吗？
不包含。它根据纪元标识一个时间点。生成本地日历字段时才会应用命名时区。
0使用哪个时区？
在常见模型中，UNIX 值 0 对应 1970-01-01 00:00:00 UTC。本地视图可能显示不同日期或时间。
为什么我的转换器显示 1970 年？
最常见原因是单位错误。按毫秒处理的秒值会停留在纪元附近。请确认单位。
为什么两个转换器相差一小时？
它们可能使用不同的时区、季节性规则、数据库版本或歧义规则。请比较 UTC 输出和命名时区。
UTC 等于 GMT 吗？
在日常偏移显示中，它们通常可以互换。它们有不同的技术历史。明确协议和标准请使用 UTC。
重复会议只存一个 UTC 时间戳可以吗？
如果会议必须保持本地时间，则不可以。请存储命名时区和重复语义。使用当前规则计算未来时间点。
应使用 ISO 8601 还是 UNIX 时间？
请为接口选择合适表示。RFC-3339 文本可读并包含偏移量。整数紧凑，但需要有文档的单位。两者都可以表示相同时间点。
最终转换规则
UNIX 时间戳标识时间点。时区解释该时间点如何显示在本地时钟上。请将这两个概念分开。
转换前确认单位。保留整数精度。将 UTC 作为稳定引用显示。使用 IANA 时区生成本地输出。测试季节性边界和历史数据。这些步骤可以在生产数据前阻止大多数错误。