我注意到，我們與時區東部時區（「美國/紐約」）偏移的「-05：00」 Date.getTimezoneOffset（）返回300。正號我會在幾分鐘內指望偏移在Utc西部地區爲負值，在Utc東部地區爲正值，但顯然這是「翻轉」的。這個決定背後的推理是什麼？爲什麼JavaScript Date.getTimezoneOffset（）將「-05：00」視爲正偏移量？
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/設定初始「時區」參數時不翻轉數。這是錯的嗎？
因爲這就是它的定義。引用美國商務部（MDN）：
的時區偏移量的區別，以分鐘爲單位，UTC和 本地時間之間。請注意，這意味着如果 本地時區在UTC之後，則偏移量爲正值，如果它在前面則爲負值。
在闡述raina77ow是完全可以接受的答案有點...
首先，要明白的是，這裏所涉及的主要標準是ISO 8601和RFC 822（及其親屬733，1123 & 2822），這是所有（在部分）來自ANSI X3.51-1975。
所有這些標準都使用UTC/GMT以東的正值和UTC/GMT以西的負值。
，我意識到有逆轉的唯一標準是POSIX（見the timezone tag wiki的POSIX部分，this article），從而解釋了爲什麼像「ETC/GMT + 5」的向後兼容性奧爾森時區都有自己的標誌倒置。 （當然有可能有其他用法，我只是不知道他們。）
信不信由你，JavaScript會這樣做。當作爲字符串使用時（使用RFC 822或ISO 8601語法），它使用UTC和UTC的正數偏移量East的小時和分鐘。但是當調用Date對象上的getTimezoneOffset()方法時，它將返回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。
Matt，我很驚訝Noda Time的Offset結構不符合這些標準。文檔說明： 「正值表示當地時間超過UTC（例如歐洲）;負值表示當地時間低於UTC（例如美國）。」 http://nodatime.org/1.1.x/api/html/T_NodaTime_Offset.htm 我剛剛收到一個報告給我的錯誤，因爲我認爲這是相反的。 – vkelman
我也使用Moment.js，並通過Moment.parseZone（）.zone（）（正如我們在另一篇文章http://goo.gl/9EaxG5中與您討論的）對由字符串解析的偏移量進行比較，野田時間，有點混亂。 – vkelman
@vkelman - 我不知道你在做什麼。野田做對了。這只是反轉的JavaScripts'getTimeZoneOffset'。 Moment可以處理任何形式，在傳遞數字時使用JS的方式（向西爲正），或者在以字符串形式傳遞時使用ISO方式（向東爲正）。請參見[本文的這一部分]（http://momentjs.com/docs/#/manipulating/timezone-offset/） –
右，時區偏移量是相對於本地的。例如，如果您居住在-01：00區域，則UTC比您提前60分鐘，或+60。 – lemieuxster
我腦海中的問題是爲什麼他們這樣設計它。 – Andy
@ Andy--因爲javascript Date對象是Java日期對象，疣和所有（甚至是2位* getYear *方法）的副本。 – RobG