为什么 JavaScript Date.getTimezoneOffset() 将“-05:00”视为正偏移量？答案

【问题标题】：Why does JavaScript Date.getTimezoneOffset() consider "-05:00" as a positive offset?为什么 JavaScript Date.getTimezoneOffset() 将“-05:00”视为正偏移量？
【发布时间】：2014-02-01 20:33:46
【问题描述】：

我注意到，对于我们在东部时区（“America/New_York”），时区偏移为 “-05:00” Date.getTimezoneOffset() 返回一个正 300 的数量。我预计从 Utc 到西部的区域以分钟为单位的偏移量是负数，而在 Utc 以东的区域是正数，但显然它是“翻转的”。这个决定背后的原因是什么？

http://momentjs.com/ 遵循相同的规则并返回...

moment.parseZone("01/13/2014 3:38:00 PM +01:00").zone()   // == -60
moment.parseZone("01/13/2014 3:38:00 PM -01:00").zone()   // == 60

同时 DateTimePicker http://trentrichardson.com/examples/timepicker/ 在设置其初始 'timezone' 参数时不会翻转数字。错了吗？

【问题讨论】：

标签： javascript timezone datetimepicker momentjs timezone-offset

【解决方案1】：

因为它是这样定义的。引用文档（MDN）：

时区偏移量是 UTC 和当地时间。请注意，这意味着 偏移量是正的，如果本地时区落后于 UTC，如果领先则为负数。

【讨论】：

对，时区偏移是相对于本地的。例如，如果您居住在 -01:00 区域，则 UTC 比您早 60 分钟，或 +60。
我心中的问题是他们为什么要这样设计它。
@Andy——因为 javascript Date 对象是 Java 日期对象的一个副本，包括 warts 和所有（甚至是 2 位 getYear 方法）。
@RobG heh，这证实了我长期以来一直想知道的事情！
要解决这个问题，只需将结果乘以减号 (-)。这样你就会得到你想要的。

【解决方案2】：

详细说明raina77ow 完全可以接受的答案...

首先，了解这里涉及的主要标准是ISO 8601 和RFC 822（及其相关的733、1123 和2822），它们都（部分）从ANSI X3 派生。 51-1975。

所有这些标准都使用正值表示 UTC/GMT 以东和负值表示 UTC/GMT 以西的约定。

我知道的唯一相反的标准是 POSIX（请参阅 the timezone tag wiki 和 this article 的 POSIX 部分），从而解释了为什么向后兼容 Olson 时区，如“Etc/GMT+5 “把他们的符号倒过来。（当然可能还有其他用法，我只是不知道。）

信不信由你，JavaScript 是双向的。当用作字符串时（在 RFC 822 或 ISO 8601 语法中），它使用带有正偏移量的小时和分钟 UTCEast。但是当在Date 对象上调用getTimezoneOffset() 方法时，它返回的整分钟都是UTC 的正West。

人们只能推测为什么存在这种不一致。 ECMAScript spec 充满了这样的问题。可能是因为当您在 ISO 8601 或 RFC 822 字符串中看到偏移量时，该偏移量已经被应用了。但是，当您调用 getTimezoneOffset() 时，它是 to 应用的偏移量，以将其带回 UTC。

例如，2014-01-01T00:00:00-05:00 等于 2014-01-01T05:00:00Z。所以getTimezoneOffset() 会返回300。如果将原始值加上 300 分钟，则返回 UTC。

这是同一枚硬币的两个方面。看到了吗？

关于特定控制是否不正确，我不确定。我不熟悉那个特定的控件。我在他们的文档中看到 -0400 等于 -240 的示例，人们可能希望将其反转，但是再次将像 -240 这样的值呈现给用户有点奇怪。确实，您不应该以任何一种方式向用户公开偏移量（恕我直言）。最好使用时区选择器控件，例如 this one 或 this one。

【讨论】：

Matt，我很惊讶 Noda Time 的 Offset 结构没有遵循这些标准。文档说：“正值意味着本地时间早于 UTC（例如欧洲）；负值意味着本地时间落后于 UTC（例如美国）。” nodatime.org/1.1.x/api/html/T_NodaTime_Offset.htm我刚刚收到一个错误报告给我，因为我认为它正在做相反的事情。
我也在使用 Moment.js 并且正在比较 Moment.parseZone().zone() 从字符串解析的偏移量（正如我们在另一篇文章中与您讨论的 goo.gl/9EaxG5）与返回的偏移量野田时间，有点乱。
@vkelman - 我不确定你在说什么。野田做对了。只有 JavaScripts getTimeZoneOffset 被反转。 Moment 处理任何一种形式，在传递数字时使用 JS 的方式（向西为正），或者在作为字符串传递时使用 ISO 的方式（向东为正）。见this part of the moment docs
但是在 Noda Time 中，当您使用 Offset..Milliseconds / (60000) 来获得偏移分钟（一个数字）时，UTC 以西的区域是负数。对于同一区域，给定格式正确的 DateTimeZone 字符串来创建 Moment 并使用 Moment.parseZone().zone() 我们得到正的分钟数。我认为 Noda TimeOffset.Milliseconds() 正确（但令人困惑）的事情是返回 UTC 以西区域的正数。
这可能最好在 Noda Time 小组中讨论，但我不会说 Moment 所做的事情与 Noda 相比或多或少是正确的，它只是受到了不同来源的影响。