我注意到我们在东部时区（“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”参数时不会翻转数字。这是错的吗？
答案 0 :(得分：62)
因为它是如何定义的。引用文档（MDN）：
时区偏移是UTC和之间的差异，以分钟为单位 当地时间。请注意，这意味着偏移量为正值 当地时区落后于UTC，如果提前，则为负时。
答案 1 :(得分：13)
在raina77ow上详细阐述了一个完全可以接受的答案......
首先，要了解此处涉及的主要标准是ISO 8601和RFC 822（及其亲属733，1123＆amp; 2822）， all（in-part）派生自ANSI X3.51-1975。
所有这些标准都使用正值为UTC / GMT以东的惯例，负值为UTC / GMT以西。
我所知道的唯一标准是POSIX（参见the timezone tag wiki的POSIX部分和this article），从而解释了为什么向后兼容的Olson时区如“Etc” / GMT + 5“他们的标志被倒置了。 （当然有可能还有其他用法，我只是没有意识到它们。）
信不信由你，JavaScript做到了两种方式。当用作字符串（在RFC 822或ISO 8601语法中）时，它使用UTC的正偏移 East 的小时和分钟。但是当在getTimezoneOffset()对象上调用Date方法时，它会返回UTC的正 West 的整个分钟。
人们只能推测为什么存在这种不一致。 ECMAScript spec充满了这样的问题。也许是因为当您在ISO 8601或RFC 822字符串中看到偏移量时，该偏移量已经已经应用。但是，当您致电getTimezoneOffset()时， 的偏移量适用于将其恢复为UTC。
例如，2014-01-01T00:00:00-05:00等于2014-01-01T05:00:00Z。因此getTimezoneOffset()将返回300。如果您将300分钟添加到原始值，则会返回UTC。
这是同一枚硬币的两面。见
关于该具体控制是否不正确，我不确定。我不熟悉那个特定的控件。我在他们的文档中看到-0400等于-240的例子，其中一个可能会被反转，但是再次向用户提供像-240这样的值有点奇怪。实际上，你不应该向用户公开偏移量（恕我直言）。您最好使用时区选择器控件，例如this one或this one。