2 回答

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

TA貢獻(xiàn)1775條經(jīng)驗(yàn) 獲得超11個贊
我已經(jīng)確認(rèn)這是JavaScript中的錯誤。
在遵循夏時(shí)制的美國常見時(shí)區(qū)進(jìn)行測試
東部,中部,山脈,太平洋
已在Chrome,F(xiàn)irefox,Safari中測試,并且失?。ㄗ钚掳姹荆?/p>
在IE 6、7、8、9中進(jìn)行了測試,但失敗了。
在IE 10中測試并通過(不受影響)。
在Windows 7、8和Mac OSX上進(jìn)行了測試。
這很麻煩。有人知道根本原因嗎?
我以為可能是WebKit錯誤,但是Firefox使用Gecko。
我檢查了各種問題列表,在任何地方都找不到此特定問題。也許我錯過了一些東西。我不確定在哪里提交錯誤報(bào)告,因?yàn)樗鼤绊懚鄠€地方。
也許這是JavaScript的核心錯誤?我真的很難相信這個基本的東西已經(jīng)被單元測試所忽略了。
我認(rèn)為這可能只是影響Windows系統(tǒng),因?yàn)樵摬僮飨到y(tǒng)具有Windows時(shí)區(qū)而不是TZDB,但是事實(shí)并非如此,因?yàn)樗舶l(fā)生在Mac上。
我們都知道JavaScript日期是很麻煩的,但是我認(rèn)為我們至少可以依靠它。您甚至不必查看偏移量,也不必進(jìn)行解析。只需檢查以下值:
new Date(2004,10,4) // recall, js months are 0-11, so this is Nov. 4 2004.
在2004年的美國,夏令時(shí)于10月31日的凌晨2:00結(jié)束,而時(shí)鐘又回到了凌晨1:00。因此,到11月4日,他們肯定都應(yīng)該在標(biāo)準(zhǔn)時(shí)間上,但事實(shí)并非如此!例如,在控制臺上的Chrome開發(fā)者工具中,時(shí)鐘設(shè)置為美國東部時(shí)區(qū):
> 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月的第一個星期日”規(guī)則之后的,但是在2004年,該規(guī)則應(yīng)該是“ 10月的最后一個星期日”的舊規(guī)則。
更新1
它似乎限于瀏覽器。 它還在Node.js中失敗
只是為了證明IE很好,這是IE10的輸出:
有趣的是,IE和Firefox將1:00歧義解決為“夏令時(shí)”,而Chrome將其解決為標(biāo)準(zhǔn)時(shí)間,但這是一個單獨(dú)的問題。它確實(shí)選擇了正確的過渡日期。
更新2
值得一提的是,在最新的Firefox 21中,確實(shí)發(fā)生了此問題,但其呈現(xiàn)方式卻有所不同,因?yàn)榧词故褂昧苏_的偏移量,另一個問題卻又切換了標(biāo)準(zhǔn)名稱的白天設(shè)置。換句話說,在Firefox上,輸出如下:
添加回答
舉報(bào)