美国永久夏令时，这对 date.getTimezoneOffset() 意味着什么

发布于 2025-01-16 09:31:04 字数 420 浏览 0 评论 0 原文

参议院周二一致批准了一项措施，明年将在全美范围内永久实行夏令时。这项名为《阳光保护法案》的两党法案将确保美国人不再需要每年两次改变时钟。

我很好奇明年的结果会是什么？ javascript如何在幕后调整结果？

const date = new Date();
date.getTimezoneOffset();

原文

The Senate unanimously approved a measure Tuesday that would make daylight saving time permanent across the United States next year. The bipartisan bill, named the Sunshine Protection Act, would ensure Americans would no longer have to change their clocks twice a year.

I am curious to know what the result would be next year? How javascript adjusts the result behind the scene?

const date = new Date();
date.getTimezoneOffset();

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

提笔落墨 2025-01-23 09:31:04

有几件事：

只有参议院法案 (S.623 ）已经过去了。相应的众议院法案（HR69）仍需通过，然后文本需要由总统签署成为法律，然后才会发生任何改变。
参议院法案规定生效日期为 2023 年 11 月 5 日（DST 将于 2023 年结束）。假设最终法律实施，则有合理的时间来实施、测试和分发所需的更改。
处理此类更改的流程已经生效，因为时区规则（包括夏令时更改）可能在世界任何地方随时发生。除了确保定期更新之外，您不必做任何特别的事情，无论如何您都应该这样做。
计算中的时区数据在 IANA TZ 讨论列表上进行协调。大多数公司从那里获取时区数据。关于这一潜在变化，目前正在进行一些积极的讨论，您可以阅读并参与这些讨论（请参阅 2022 年 3 月在档案中）。
时间变化本身相当简单。我们从该法案中了解到各个受影响时区的时钟将如何变化。主要的讨论/辩论是围绕命名约定的相关变化。
- 例如，西海岸现在永远处于“PDT”状态，还是说“PST”且含义已发生变化。亚利桑那州是否开始使用“MDT”或“PST”，或者是否一直说“MST”，即使这与山区其他时间相差一个小时。等等
平台和软件库供应商将采用该更新。它最终将进入浏览器和其他 JavaScript 环境。
getTimezoneOffset 将返回调用它的 Date 对象所反映的时间点的正确时区偏移量。
- 如果您在 new Date() 上调用它，您将请求当前时区偏移量，因此它将继续像今天一样运行（返回2023 年 11 月 5 日之前有效的标准偏移量或日光偏移量。然后它将返回此后更新的偏移量。
- 如果您在 2023 年 11 月 5 日之后的未来日期调用它，如果您的时区数据尚未更新，您将看到旧的（标准时间）偏移量，但您将看到新的（夏令时）偏移量一旦数据通过任何适用的更新到达您的环境。

A few things:

Only the Senate bill (S.623) has passed. The corresponding House bill (H.R.69) still needs to pass, and then the text needs to be signed into law by the President before anything would change.
The Senate bill has a built-in effective date of November 5, 2023 (the day DST would have ended in 2023). Presuming that carries into the final law, there is a reasonable amount of time for the required changes to be implemented, tested, and distributed.
The process for handling such changes is already in effect, as time zone rules (including daylight saving time changes) can occur at any time from any part of the world. You won't have to do anything in particular, other than ensure you are keeping up with regular updates, which you should be doing anyway.
Time zone data in computing is coordinated on the IANA TZ discussion list. Most companies source their time zone data from there. There are several active discussions in process about this potential change, which you can read and participate in (see March 2022 in the archives).
The time change itself is fairly straightforward. We know from the bill how the clocks will change in the various affected time zones. The main discussion/debate is around the associated change in naming conventions.
- For example, is the west coast now forever on "PDT", or does it say "PST" and the meaning has changed. Does Arizona start using "MDT", or "PST", or does it keep saying "MST" even if that's an hour off from the rest of Mountain time. etc.
After the change is enacted into law, IANA will release a tzdata update, which will get picked up by the various operating system, programming language platform, and software library vendors that depend on it. It will eventually make its way to the browser and other JavaScript environments.
getTimezoneOffset will return the correct time zone offset for the point in time reflected by the Date object it's called on.
- If you call it on new Date(), you're asking for the current time zone offset, so it will continue to behave as it does today (returning either the standard or the daylight offset that is in effect) until November 5th, 2023. Then it will return the updated offset from then forward.
- If you call it on a future date, after November 5th 2023, you will see the old (standard time) offset if your time zone data hasn't yet been updated, but you will see the new (daylight time) offset once the data has reached your environment by whatever update is applicable.