新日期中的毫秒會產生意想不到的結果

不確定我在這裏做錯了什麼。當我執行這個語句：新日期中的毫秒會產生意想不到的結果

new Date(43 * 365 * 24 * 60 * 60 * 1000) // ms from Epoch to Jan 1st, 2013

我得到這個：

Thu Dec 20 19:00:00 EST 2012

我覺得我明明半睡眠狀態，因爲我敢肯定，這應該按預期工作（顯然不是;））。

更新：謝謝大家 - 是的，我完全忘了從閏年日跌幅。作爲其他人的參考，你可以在這裏找到更多的細節： http://www.wikihow.com/Calculate-Leap-Years

來源

2013-11-14 James Wilkins

這是工作如預期，因爲在1/1/1970午夜UTC該毫秒數是基於關閉的天數。

（爲什麼11天，除了時差相差有11閏年的時期和2013年1月1日之間？）

來源

2013-11-14 23:55:26 pobrelkey

啊，是的，我忘了這一點。我看到許多將毫秒轉換爲年，日，年，小時，分秒的例子，並且他們都被接受了答案，但我認爲很多人沒有考慮到這一點。謝謝。 –

不要忘記，每年都沒有365天。另外，如果您使用日期的方式使用date.js是個好主意。

來源

2013-11-14 23:53:27

不，這不是 - 爲什麼必須這樣每一個細小的問題得到解決由一些圖書館。此外，從我聽到的信息來看，moment.js更好（更小），並更經常更新。 Date.js自2010年以來一直未更新，主頁自2008年以來一直如此。 –

您說得對，moment.js更好。其次，沒有理由不使用像moment.js這樣的小型庫，因爲如果從流行的cdn中獲取代碼，它會使代碼更易於被修改，並且對加載時間的影響可以忽略不計。 –

我的意思是我這樣簡單的例子，得到整個圖書館是矯枉過正。如果我正在做很多與日期相關的工作，那麼是的，這是有道理的（正如你在帖子中提到的那樣）。爲節省時間而抽出工作對業務有好處，但是對於經驗較少的編碼員而言。 ;）應該引導人們首先用解決方案解決手頭的問題，然後用最終的方法解決問題，如果不想學習或花時間，則需要爲圖書館提供參考資料。 :)在這種情況下，我被指示查找閏年計算並學到很多東西。 –

爲什麼不使用顯式構造函數？例如。

new Date(year, month, day, hours, minutes, seconds, milliseconds)

朱利安構造，因爲01/01/1970

來源

2013-11-14 23:54:23 codemonkeh

很簡單，因爲這不是我需要做的。 :)我有我的理由。 –

然後公平的。只要小心閏年:) – codemonkeh

是的。我現在感到很蠢，因爲我知道閏年。我只是稍微有一點腦迷霧，將它與DST混淆 - 目前還沒意識到它實際上意味着整整一天的損失。大聲笑。 :) –

新日期中的毫秒會產生意想不到的結果

回答

相關問題