2016-10-24 85 views
0

當我檢測到一個奇怪的行爲時,所有問題開始:我有一個很長的數字,意思是「自0001/01/01以來的毫秒數」,然後在C#日期時間使用AddMilliseconds得到一個不同的日期值,即一個小時內返回的日期值。例如。處理日期時的時刻日期問題

new DateTime().AddMilliseconds(63613091700000); => {10/26/2016 3:15:00 PM} 
moment([1]).add(63613091700000).toDate()   => Wed Oct 26 2016 16:15:00 GMT-0400 (Eastern Daylight Time) 

在C#中獲得15:15h,並在當下16:15 !!!

那吹我的腦海裏,所以我搜索了錯誤,我發現它:

moment([1]).toDate() => Mon Jan 01 1 00:00:00 GMT-0500 (Eastern Standard Time) 

的問題是,當我創建一個自定義的日期(moment([1]))目前它使用GMT-0500 (Eastern Standard Time)但申請時當時add方法返回GMT-0400 (Eastern Daylight Time)!另請檢查通過moment()創建時間日期還是使用javascript日期new Date()也使用GMT-0400 (Eastern Daylight Time)。這就是問題所在。

我的問題是,爲什麼會發生這種情況?這是一個問題嗎?

+3

發生這種情況是因爲那是您在運行JavaScript的系統上設置的時區。此外,回到耶穌出生時,似乎是一個奇怪的事情,通常JavaScript從1970年開始計算,而不是0001. – adeneo

+1

存儲和操縱UTC中的所有日期。使用用戶的本地時區/ DST設置對使用用戶界面進行日期時間處理的最後一件事情是使用用戶的本地時區/ DST設置進行格式化,從UI接收日期時間後使用日期時間進行的第一件事是將其轉換爲UTC。 –

+1

@adeneo很確定耶穌不是在0001/12/25之前出生的。充足的時間。 –

回答

0

我發現發生了什麼,但沒有如何處理它: 問題是JavaScript的Is Daylight Saving Time

http://momentjs.com/docs/#/query/is-daylight-saving-time/

moment([2011, 2, 12]).isDST(); // false, March 12 2011 is not DST 
moment([2011, 2, 14]).isDST(); // true, March 14 2011 is DST 

的事情是,當我這樣做moment([1]).add(63613091700000).toDate()它計算以正確的方式,但結果的日期時間是在DST所以它改造它。這次我不希望這種行爲。

+0

**所有ECMAScript日期對象都是UTC **,它們沒有時區偏移量。主機系統偏移量用於在創建日期時計算UTC值,然後還用於生成「本地」字符串以及何時使用非UTC方法。如果您想查看UTC時間,請使用* toISOString *。 – RobG

1

ECMAScript將夏令時規則視爲始終應用,即使在夏令時被引入之前。

如果在主機設置爲美國EST時區時創建0001-01-01的日期,則不存在夏令時(因爲美國EDT從3月運行到11月初),因此UTC時間值是針對0001- 01-01T00:00:00-0500或0001-01-01T05:00:00Z(他們在同一時間)。

在同一臺主機上,如果在當天有夏令時的地方添加足夠的毫秒數以達到2016-10-26 15:15:00-0500,則時間將增加1小時,因爲不同的夏令時偏移量,所以時間顯示爲16:15:00或完整:2016-10-26T16:15:00-0400。

但是請注意,2016-10-26T15:15:00-0500和2016-10-26T16:15:00-0400在時間上完全相同(相當於2016-10-26T20:15:00Z ),唯一的區別是時區偏移量。

如果要顯示UTC以外的特定時區的日期和時間,請使用moment-timezone.js