简体中文

开发者工具·Unix时间戳转换器

浏览器如何使用 Date 和 Intl 将纪元转换为本地时间

· 工作原理

时间戳 JavaScript 浏览器 API

一个纪元进入浏览器并作为 UTC 和本地时钟读数出现
原始 ToolAcre 矢量图

浏览器转换器没有自己的服务器时钟或时区数据库;它依赖于操作系统支持的 Date 对象和 Intl API。这篇文章解释了该管道及其局限性。

浏览器从哪里获取“本地”? — 同一时代在同一房间的笔记本电脑和手机上显示不同

当配置的本地区域不同时,彼此相邻的两个设备可以以不同的方式渲染一个纪元。笔记本电脑和手机之间的整数不变;每个浏览器构建相同的时刻,然后为其自己的环境提供本地日历字段。因此,“本地”描述的是读者,而不是时代内部的财产。

ToolAcre 通过使用 `Intl.DateTimeFormat().resolvedOptions().timeZone` 标记本地行,使该依赖关系可见。显示一个时钟时间的屏幕截图和显示另一个时钟时间的服务器日志可能都是忠实的读数。首先比较它们的 UTC 行;匹配 UTC 输出表明呈现不同,而不是底层瞬时不同。

Date 需要毫秒——构造函数的约定,为什么秒必须乘以千,以及 Date 可以表示的范围

JavaScript `Date` 从纪元接收毫秒。 ToolAcre 的 `fromEpoch` 将秒输入乘以 1,000 并在构造对象之前保持毫秒输入不变。该转换是显式的,因为将 1,717,243,200 直接传递给 `new Date` 意味着 1970 之后大约二十天,而不是 6 月 2024。

该实现在格式化之前拒绝非有限数字和任何超出 ±8.64×1015 毫秒的解释值。该限制来自源中指定的日期范围,而不是来自数据库或操作系统时钟。更改选择器可以将值移动到边界之外,因此错误还会告诉您应用了哪个单位。

UTC 访问器与本地访问器 — getUTCHours 和 getHours,以及引擎如何应用偏移量

ToolAcre 不会提取带有 `getUTCHours` 和 `getHours` 的字段;大纲的访问器措辞比实现更具体。它要求 `Intl.DateTimeFormat` 使用 `timeZone: "UTC"` 格式化日期一次,并在没有区域覆盖的情况下格式化一次。两个调用都接收相同的毫秒值,因此两者都无法移动事件本身。

这种区别在调试时很重要。如果秒和毫秒行与生产者一致,但本地标签让您感到惊讶,请检查浏览器区域,而不是向纪元添加小时。手动偏移算术将创建一个不同的时刻,然后让格式化程序再次应用本地规则,从而产生经典的双重调整错误。

UTC 和本地格式要求引擎提供一个日期的两个读数

转换器可以证明它向浏览器请求 `resolvedOptions().timeZone`;它无法证明特定引擎是否从操作系统、捆绑数据或其他平台层获取了每个时区规则。源故意将该机器视为引擎责任,如果区域查询失败,则返回到短语“本地时间”。

这个证据边界很有用。结果中的命名区域标识了浏览器的当前选择,但它不是时区数据库的版本报告。如果两个环境在旧日期上不一致,请记录浏览器、操作系统和显示区域。转换器提供观测值;它不诊断 Intl 后面的数据包。

浏览器报告本地区域,而其规则源仍然是实现细节

对于 ISO 行,`toISOString()` 提供带有尾随 Z 和三个小数位的 UTC 字符串。人类可读的 UTC 和本地行使用英国英语格式化程序,其中包含数字年份、缩写月份、两位数日期和 24 小时时钟。格式化程序还请求 `shortOffset`,使每个呈现行的适用偏移部分成为可能。

这些选择解释了为什么从控制台复制 `Date.toString()` 不是等效证据。它的确切散文取决于语言环境,并且超出了该工具的输出合同。 ToolAcre 修复了其显示选项,同时仍然允许实际的本地区域发生变化。当另一个系统需要稳定的机器可读比较时复制 ISO 值。

工作示例:一个纪元,三个输出 - 一个 UTC ISO 字符串、一个本地格式的时间以及与 getTimezoneOffset 的分钟偏移量

输入 1,717,243,200 并选择秒。乘法产生 1,717,243,200,000 毫秒,测试将其确定为 `2024-06-01T12:00:00.000Z`。 UTC 行格式以 UTC 表示;本地行在浏览器区域中格式化相同的日期并命名该区域。秒和毫秒行保留两种数字形式。

必须从运行示例的设备读取精确的本地时钟和偏移量;在这里发布一篇文章会假装每个读者都有相同的区域。这就是为什么此有效检查使用 ISO 断言作为其固定结果并将本地输出视为观察值的原因。如果 ISO 不同,请在调查位置设置之前重新访问所选设备。

工作示例:一个纪元,ToolAcre 实际公开的三个输出

该路线不提供任意第三区域的选择器。 `formatInZone` 可以在内部接受区域,但面板仅针对 UTC 和浏览器默认值调用它。一篇声称用户可以选择东京、内罗毕或多伦多的文章描述了一个尚未发布的界面,尽管 Intl 在其他地方可以支持此类格式。

它也不会公开日历选择、区域设置选择或时区数据库修订。对于跨办公室转换,保留纪元作为锚点并使用其记录界面命名目标区域的工具。在这里,更狭隘的承诺是有价值的:本地环境旁边的通用 UTC,没有隐藏的服务器来决定本地的含义。

要点:您的浏览器是时钟和地图集 — 以及 Unix 时间戳转换器如何使用它在没有服务器的情况下并排显示 UTC 和本地时间

浏览器既充当算术引擎又充当演示环境。 ToolAcre 解析单位,创建一个日期,请求规范的 ISO 值,然后并排格式化 UTC 和本地读数。这些步骤不需要远程转换服务,并且显示的单位会保留 1,000 因子的决策可供审核。

当设备之间的输出不一致时,按顺序比较 ISO 行、单位注释和指定的本地区域。这三个观察将即时、规模和呈现分开。将本地时钟视为事实来源会将所有三个问题合并为一个,并且每当观看者改变区域时,正确的转换就会显得错误。