我错过的最昂贵的会议安排得很正确。伦敦有人把 "3pm 我的时间,上午 10 点 yours"在纽约的一个日历邀请我,这是他们在 2 月份写的时候的真实情况。电话是在 3 月 12 日。美国在上一个星期天已经把时钟向前移动了;英国没有,而且不会再持续三周。伦敦和纽约之间的差距,通常为五个小时,那周是四个--所以伦敦的下午 3 点对我来说是上午 11 点,而不是上午 10 点。我提前一个小时加入了一个空房间,放弃了,完全错过了电话。
春天的三周窗口- 秋天的一周窗口- 不是边缘案例,它每年都会发生,它会抓住那些在算术方面完全胜任的人,因为算术不是问题,因为"伦敦比纽约"早五个小时,这不是关于两个城市的事实,而是关于两个城市的事实 在特定日期并且当您将其写下而不附加日期的那一刻,您就创建了一个错误。
A时区不是偏移量,它是一套规则,当你瞬间喂它时,它会产生偏移量,那些规则会改变:国家采用夏令时,放弃它,改变他们的标准偏移量,或者宣布永久改变三周'通知,这就是为什么 时区转换器 上 Toolz.dev 从来不会在任何地方存储偏移量。它问 伊娜 时区数据库 - 已经位于浏览器内的数据库 - 您正在转换的确切时刻的偏移量是多少,并且它会再次询问每隔一刻。
TL;博士: 两个区域之间的差距取决于日期,因为夏令时过渡并不在国家之间排队。 时区转换器 IANA数据库解析您输入的特定瞬间的每个偏移量,同时显示UTC偏移量和签名的差异,处理半小时和四分之一小时区域,并在会议策划者条中跨几个城市放置相同的瞬间,完全在您的浏览器中运行。
主要特点
每秒解决偏移量,从未硬编码
该工具中的每个偏移量都是通过将您的即时格式化到目标区域并读回挂钟来计算的。单一的设计决策意味着夏令时、历史规则变化以及政府法令调整其偏移量的国家/地区均由相同的代码路径处理。没有偏移表可供维护,也没有表可供陈旧。将柏林和芝加哥之间的 1 月会议和 7 月同一次会议转换为该工具,两次都会正确地为您提供 7 小时的间隙 - 但在 3 月下旬转换为一个,它将正确地为您提供 6 个。
50多个策划的IANA区域
Picker列出了人们实际安排的城市, 按地区分组, 标有他们的国家, 并与完整的IANA标识符一起显示。最后部分比看起来更重要: Asia/Kolkata 是您粘贴到 cron 表达式 Postgres 中的字符串 AT TIME ZONE 子句,或者 Python ZoneInfo 构造函数。阅读和引用;加尔各答,印度"和复制 Asia/Kolkata 是两个不同的工作,而该工具两者兼而有之。
会议策划条
在转换下方,您添加的每个区域都会获得一排小时单元格,横跨瞬间的窗口。工作时间(当地时间 09:00 至 17:59)有阴影,早班和晚班分别标记,任何落在不同日历日的单元格都带有 a +1d 或 -1d badge。finding一个小时,在旧金山,伦敦和悉尼同时文明是一个难题 - 带使它成为视觉而不是算术。
半小时和一刻钟区域按正常处理
UTC + 05:30印度是UTC + 05:45尼泊尔是UTC + 05:45阿德莱德是UTC + 09:30冬季和UTC + 10:30夏季查塔姆群岛是UTC + 12:45大约是世界五分之一's人口生活在一个偏移量不是整数小时,任何假设否则的工具对亿万人的错误这里的偏移量存储和显示在几分钟。
显示您输入日期的缩写
转换的每一侧都显示该时刻有效的区域缩写 - EST 或 EDT、GMT 或 BST、AEST 或 AEDT。这是查看您登陆过渡的哪一侧的最快方法。如果您输入 3 月份的日期,工具上写着 EDT,则时钟已经更改。如果它写着 EST,则它们没有。
完全客户端
每个计算都使用浏览器中的 JavaScript 运行 Intl API和随引擎附送的时区数据库,你输入的东西都上传不上传,也没有记录,一旦页面加载了转换器就一直工作,根本没有网络连接,那也意味着你更改字段的瞬间结果更新,因为没有来回等待。
如何使用时区转换器
1步:设置源区、日期和时间
选择你正在皈依的城市 从,然后输入日期和时间,与时钟在那里读取的完全一致,时间字段需要24小时值,因此下午3点为 15:00.如果你想要当下而不是假设的那一刻,按 现在- 它加载源区域中看到的当前日期和时间,这不一定与您自己墙上的日期相同。
2步:选择目标区域
选择您想要答案的城市。转换后的日期、时间和 12 小时读数立即出现,以及适用于该特定日期的 UTC 偏移量和缩写。请注意 日期 可以更改:纽约周一 21:00 是达卡周二 07:00,该工具会显示新的日期,而不是悄悄地让您解决问题。
3步:读取偏移量和间隙
在每一侧下方,您都会得到偏移 UTC±HH:MM form 和 zone 缩写,在它们之间,工具用单词 - "达卡比纽约 " 提前 10 小时 - 带有该日期的正确值,而不是记忆的平均值。使用交换按钮反转方向;它保持不变 瞬间 并翻转你要进入的哪一侧,这几乎是你总是想要的。
4步:构建会议条
将每个参与者's区域添加到规划器中,每一行在该区域中显示相同的瞬间加上周围的时间,工作时间有阴影。提前或稍后滑动您的源时间并观看阴影移动。当阴影单元格在每一行排队时,您已找到您的插槽。
5步:复制结果
只复制转换后的时间,或完整表达式 - Sun, Mar 12, 2026 09:00 EDT (America/New_York) = Sun, Mar 12, 2026 13:00 GMT (Europe/London)- 并粘贴到日历邀请函中。用缩写写出两面是不要重复我的伦敦错误的最有效的单一习惯。
时区转换的实际工作原理
Naive mental model,每个区都附着一个数字,转换就是减法,那个模型在大多数时候产生正确答案的方式上是错误的,这是最糟糕的失败模式。
正确的模型有三层。
第一层:瞬间。 凡事之下,都是通用时间线上的一个点- 纪元时间戳,自1970-01-01T00:00:00Z以来的秒数 瞬间是明确的,地球上的每个人同时经历相同的瞬间,无论他们的时钟说什么。
第二层:偏移。 偏移量是添加到 UTC 以获得本地挂钟时间的签名分钟数。 UTC-04:00 是偏移量,它是 a 结果的,不是一个地方的财产。
第三层:区域。 A区是一组命名规则- America/New_York- 那将瞬间映射到偏移量 这是人们崩溃为第二层的图层,而那个崩溃几乎是每个时区错误的来源。
所以转换不是 localB = localA + delta.它是:
instant = resolve(wallClockA, zoneA) // rules of A, applied to that reading
wallClockB = render(instant, zoneB) // rules of B, applied to that instant
2次规则查找,中间一个瞬间。工具正是这样做的。要在瞬间解决一个区域的偏移量,它会将瞬间格式化为该区域,读回年、月、日、时、分、秒,将那些字段视为 UTC,并减去真实的瞬间。差别在于偏移量,以分钟为单位,直接来自引擎's IANA数据库的副本。
向(to the other direction)- 从壁钟读数到瞬间- 有鸡蛋问题,因为需要偏移量找到瞬间,需要瞬间找到偏移量,工具使用幼稚偏移量猜测一次,检查猜测是否落在过渡的另一侧,如果有的话纠正两个查找,总是终止,跨越DST边界进行纠正。
IANA 时区数据库
IANA所依赖的数据库维护,通常仍被称为"奥尔森数据库",继20世纪80年代开始的亚瑟 · 大卫 · 奥尔森之后,它运送到每个操作系统、每个浏览器、每个JVM和每个Python安装的内部,并且每年都会更新几次,因为政府不断改变主意。
其标识符采用以下形式 Area/Location: America/New_York、 Europe/London、 Asia/Kolkata、 Australia/Sydney.地点是代表城市,不是政治主张- America/New_York 覆盖整个美国东部地区,印第安纳州众所周知需要十几个自己的标识符,因为几十年来,印第安纳州各县对于是否遵守夏令时存在分歧。
数据库存储的不是每个区域的单个偏移量而是完整的规则历史记录,它知道乌克兰's Europe/Kyiv ... Europe/Kiev 2022年更新拼写为止,它知道埃及在2014年放弃夏令时后,在2023年重新引入夏令时,它知道萨摩亚在跳过国际日期变更线时完全跳过了2011年12月30日的历史,这就是为什么将同一对城市的2015年和2025年的日期转换可以合法地产生不同的答案,以及为什么硬编码抵消的工具是谎言过去的工具。
对于任何编写软件的人来说,实际后果是: UTC 中存储瞬时,将用户's 区域存储为 IANA 标识符,并且仅在显示层进行转换。 永远不要存储偏移量 偏移量是规则的渲染,规则会发生变化。如果您直接使用 epoch 值,则 时间戳转换器 是将它们读回日期的配套工具。
UTC 偏移量、缩写和区域名称:使用
这三件事不断被混淆,而且不可互换。
| 形式 | 例子 | 穩? | 独? | 用它来 |
|---|---|---|---|---|
| IANA 区域名称 | America/New_York |
是的,跨越夏令时 | 是的 | 存储、代码、配置、API |
| UTC 偏移量 | UTC-04:00 |
不,随夏令时而变化 | 否 | 显示屏、线材格式,并立即连接 |
| 缩写 | EDT |
不,随夏令时而变化 | 否 | 仅人性化显示 |
杀手就是最后一栏,缩写不是唯一的。 CST 指美国中央标准时间、中国标准时间和古巴标准时间 - 三种不同的偏移,一个字符串。 IST 指印度标准时间、爱尔兰标准时间和以色列标准时间。 BST 意英国夏令时,还有布干维尔标准时间,如果一个系统收到 CST 通过电线,必须猜测,这对某人来说是错误的。
偏移形式明确但不稳定: UTC+01:00 正确识别瞬间's渲染,但它不是一个区域,你不能用它来计算 下一个 Tuesday's渲染,因为下周二可能会落在过渡的另一边。
IANA名字才有规则,是你应该坚持的三种中唯一的一种。
为什么两个城市之间的差距不断扩大
节约日光是原因,而节约如此激烈的原因是各国不同步过渡。
- 美国 3月的第二个星期日向前弹簧,在11月的第一个星期日回落。
- 欧盟 3月的最后一个星期日向前弹簧,在10月的最后一个星期日回落。
- 澳大利亚在南半球,情况恰恰相反:十月向前,四月回来--昆士兰州、西澳大利亚州和北领地根本不这样做。
- 印度、中国、日本、非洲大部分地区和亚洲大部分地区 任何时候都不要观察它。
将它们对齐,您会得到重叠窗口,而通常的间隙根本是错误的:
| 期间 | 纽约时钟 | 伦敦时钟 | 差距 |
|---|---|---|---|
| 冬季的大部分时间 | 美国东部时间 (UTC−05:00) | 格林尼治标准时间 (UTC+00:00) | 5个小时 |
| 三月的第二个星期日→ 三月的最后一个星期日 | 美国东部时间 (UTC−04:00) | 格林尼治标准时间 (UTC+00:00) | 4个小时 |
| 夏天的大部分时间 | 美国东部时间 (UTC−04:00) | 英国夏令时(UTC+01:00) | 5个小时 |
| 十月的最后一个星期日 → 十一月的第一个星期日 | 美国东部时间 (UTC−04:00) | 格林尼治标准时间 (UTC+00:00) | 4个小时 |
1年两个窗口- 春季大约三周,秋季大约一周- 其中每个"we're总是相隔五个小时"你的日历中的假设是关闭一个小时。而那只是一对城市。添加悉尼,其过渡方向相反,一年中不同的差距值的数量迅速攀升。
Transfition本身又制造了两个值得命名的危害,当时钟向前跳动时,当地时间一小时 不存在- 02:30在纽约的过渡之夜不是真正的读物,当时钟回落时,当地时间一小时 2次发生的,而裸露的挂钟读数是真正的模糊,转换器将不存在的时间解析为过渡后立即的瞬间,模糊的时间解析为第一次出现,这是大多数日历软件遵循的约定,它不是唯一可以防御的选择,而是产生惊喜最少的一个。
常见用例
在分布式团队中安排会议。 显而易见的一个,也是规划者条带存在的那个。三个或更多区域是心算可靠失败的地方,特别是当其中一个区域处于半小时偏移或南半球时。
撰写日历邀请和公告。 始终用区域说明时间,始终给出至少两个渲染图,并且更喜欢 IANA 名称或完全合格的缩写而不是 "我的时间 " "14:00 UTC (10:00 EDT/19:30 IST)"是明确的。 "2pm"是一种抛硬币。
日志中的调试时间戳。 UTC 服务器登录,客户在本地时间报告事件,需要对两者进行对账才能找到请求,将客户's 报告转换为 UTC,然后搜索,如果日志是 epoch 值而不是 ISO 字符串,则通过 时间戳转换器 首先。
安排亲信工作和背景工作。 UTC设置的服务器上的cron表达式不会随用户转移'夏令时更改,这通常是您想要的 - 偶尔也正是您不想要的,如果工作是要在本地09:00运行对于一个观察DST国家的客户在提交时间表之前计算出两个读数; the 克朗解析器 会告诉你你的表达方式到底是什么意思。
计划旅行并与家人通话。 14小时的航班,在每个机场总是按当地时间给出出发和到达时间,这意味着一个航班's表面的持续时间是无稽之谈,直到你将两端转换到同一区域"s在出发前到达"s的14小时航班只是一个日期线交叉口。
协调发射、部署和禁运。 任何跨多个市场的硬截止值都需要一个瞬间,以 UTC 表示,并为每个区域附上本地渲染图。如果您正在计算距离该瞬间还有多少天而不是时钟读数 日期差计算器 是工作流程的另一半。
常问问题
如何将 est 转换为 ist？
选择 America/New_York 作为来源和 Asia/Kolkata 为目标,印度在东部标准时间比纽约早10小时30分钟,在东部夏令时间比纽约早9小时30分钟,因为印度不遵守夏令时,而美国则遵守夏令时,这种变化的差距正是为什么你应该根据日期进行转换,而不是背一个数字。
eST和EDT有什么区别？
EST(东部标准时间)为UTC−05:00,适用于冬季,EDT(东部夏令时间)为UTC−04:00,适用于3月的第二个星期日到11月的第一个星期日。"东部时间"或ET是总括术语,意指当前生效的文档和代码中,更喜欢IANA标识符 America/New_York的,这全年都是明确的。
这个转换器能处理夏令时吗？
是的,它会针对您输入的日期而不是今天。每个区域's偏移量都会在您转换的特定时刻通过 IANA 时区数据库解决,因此 3 月 1 日的会议和 3 月 15 日纽约和伦敦之间的同一会议将分别正确显示五个小时的差距和四个小时的差距 - 美国比欧洲提前三周。
什么是 IANA 时区标识符？
这是一个名字 America/New_York、 Europe/London、或者 Asia/Kolkata IANA时区数据库中提取的,该数据库不仅记录当前偏移量,而且记录每个历史规则变化的参考数据集标识符是区域/位置对,它们是软件中唯一安全的命名区域的方法,因为像CST这样的缩写是模糊的- 美国中部、中国标准和古巴标准都声称。
为什么有些时区有 30 或 45 分钟的偏移？
为区域是政治性的,而不是几何性的印度在UTC + 05:30确定在一个时钟上运行一个宽阔的国家尼泊尔选择UTC + 05:45比印度提前十五分钟坐阿德莱德是UTC + 09:30查塔姆群岛是UTC + 12:45任何假设偏移是整小时的代码最终都会对全球大约五分之一's人口来说是错误的。
什么是 UTC，它与 GMT 有何不同？
UTC(协调世界时)是每个区域都定义为偏移的原子钟标准。GMT(格林威治标准时间)是冬季恰好等于UTC + 00:00的时区- 英国在夏季移至BST(UTC + 01:00),因此"GMT"和"伦敦时间"并非全年都在UTC中存储和比较瞬间;转换为仅用于显示的区域。
世界上有多少个时区？
24个理论上的一小时频段,但实际上大约有38个不同的UTC偏移在计算半小时和四分之一小时区域后才被使用,跨越UTC−12:00到UTC + 14:00,那个26小时的传播是地球上两个地方可以在同一时刻的不同日历日期的原因,IANA数据库本身定义了数百个命名区域,因为它跟踪历史规则以及当前的规则。
夏令时差距的时刻会发生什么?
时钟向前跳动时,当地时间永远不存在一个小时,所以纽约过渡之夜的02:30不是真正的读数,转换器将这样的输入解析到过渡后的瞬间,而不是默默地返回错误的答案,在秋季重叠,相同的挂钟发生两次,解析到第一次发生 - 大多数日历软件遵循的约定。
