2 回答

TA貢獻2037條經驗 獲得超6個贊
實際上是指定行為,以使用當前的DST規則,而忽略在檢查的特定日期/時間到位的規則。參見ES5 15.9.1.8:
“ ECMAScript的實現不應嘗試確定確切的時間是否受夏時制的約束,而應確定如果當時使用了當前的夏時制算法,則夏時制是否會生效。這避免了諸如此類的復雜性。考慮到該語言環境全年觀察夏令時的情況?!?/p>
規則是:將當前DST規則應用于指定的任何時間。這會導致胡言亂語,但這正是ECMAScript所要求的。
在將來的ECMAScript版本中,這種行為甚至可能會改變,要求在所有時間點都使用實際的DST規則。最初并不需要這樣做,因為它會給實現者帶來發送tzdata的負擔。語言已經變得足夠重要,但是從長遠來看,也許每個人都必須掌握它。但是就我所知,這種變化可能還需要數年,所以不要屏住呼吸。

TA貢獻1775條經驗 獲得超11個贊
我已經確認這是JavaScript中的錯誤。
在遵循夏時制的美國常見時區進行測試
東部,中部,山脈,太平洋
已在Chrome,Firefox,Safari中測試,并且失?。ㄗ钚掳姹荆?/p>
在IE 6、7、8、9中進行了測試,但失敗了。
在IE 10中測試并通過(不受影響)。
在Windows 7、8和Mac OSX上進行了測試。
這很麻煩。有人知道根本原因嗎?
我以為可能是WebKit錯誤,但是Firefox使用Gecko。
我檢查了各種問題列表,在任何地方都找不到此特定問題。也許我錯過了一些東西。我不確定在哪里提交錯誤報告,因為它會影響多個地方。
也許這是JavaScript的核心錯誤?我真的很難相信這個基本的東西已經被單元測試所忽略了。
我認為這可能只是影響Windows系統,因為該操作系統具有Windows時區而不是TZDB,但是事實并非如此,因為它也發生在Mac上。
我們都知道JavaScript日期是很麻煩的,但是我認為我們至少可以依靠它。您甚至不必查看偏移量,也不必進行解析。只需檢查以下值:
new Date(2004,10,4) // recall, js months are 0-11, so this is Nov. 4 2004.
在2004年的美國,夏令時于10月31日的凌晨2:00結束,而時鐘又回到了凌晨1:00。因此,到11月4日,他們肯定都應該在標準時間上,但事實并非如此!例如,在控制臺上的Chrome開發者工具中,時鐘設置為美國東部時區:
> new Date(2004,10,7,0,0)
Sun Nov 07 2004 00:00:00 GMT-0400 (Eastern Daylight Time)
> new Date(2004,10,7,1,0)
Sun Nov 07 2004 01:00:00 GMT-0500 (Eastern Standard Time)
過渡日期定在11月7日。這是繼目前生效的“ 11月的第一個星期日”規則之后的,但是在2004年,該規則應該是“ 10月的最后一個星期日”的舊規則。
更新1
它似乎限于瀏覽器。 它還在Node.js中失敗
只是為了證明IE很好,這是IE10的輸出:
有趣的是,IE和Firefox將1:00歧義解決為“夏令時”,而Chrome將其解決為標準時間,但這是一個單獨的問題。它確實選擇了正確的過渡日期。
更新2
值得一提的是,在最新的Firefox 21中,確實發生了此問題,但其呈現方式卻有所不同,因為即使使用了正確的偏移量,另一個問題卻又切換了標準名稱的白天設置。換句話說,在Firefox上,輸出如下:
添加回答
舉報