Почему использование JavaScript для планирования первого квартала 22034 года ненадежно в Safari? - PullRequest
2 голосов
/ 30 ноября 2010

Есть что-то подозрительное в вычислении дат далекого будущего, когда оно выполняется на стороне браузера (Safari 5.0.1), передавая строки в конструктор Date () :

Я сузил его до перехода февраль-март в 22034 году:

d = new Date('1 Mar 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

Подавая на любую более позднюю дату , конструктор всегда возвращает объект Date один за другим!

А как насчет более ранних дат? Последний день февраля выглядит хорошо:

d=new Date('28 Feb 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

Мои интуитивные ощущения говорят мне, что похоже на ошибку, связанную с високосным годом . Но какой здесь шаблон игры, чем можно объяснить ошибку?


Edit:

Как насчет того, если мы попросим 29 февраля?

d=new Date('29 Feb 22034')
Wed Mar 01 22034 00:00:00 GMT+0000 (GMT)

Возвращает последний февраль + 1 день (стандартное поведение).

1 Ответ

1 голос
/ 30 ноября 2010

Это потому, что формат даты, который вы указываете new Date(), является нестандартным.Факт, что вы получаете что-то, потому что Safari делает вам одолжение.(См. Раздел 15.9.1.15 спецификации для допустимых форматов; в основном это упрощенный ISO-8601. И наличие любого стандарта для разбора строк даты / времени является относительно новым [5-е издание].)

Если вы используете стандартный конструктор, например, new Date (22034, 2, 1) (месяцы начинаются с нуля, то есть 1 марта 22034 г.), он работает нормально.Вы можете проверить это следующим образом ( живая копия ):

display("With non-standard string: " + new Date("1 Mar 22034"));
display("Using standard constructor: " + new Date(22034, 2, 1));

Что для меня при использовании Safari для Windows приводит к:

С нестандартной строкой: Вт 28 февраля 22034 00:00:00 GMT + 0000 (стандартное время GMT)
Использование стандартного конструктора: ср. 01 марта 22034 00:00:00 GMT + 0000 (стандартное время GMT)

Как видите, в первой строке указана неправильная дата, а во второй строке указана правильная.

Стандартный конструктор также работает правильно в Chrome, Opera и Firefox (все в Ubuntu), IE6,IE7 и IE8: http://jsbin.com/ogiqu

Если бы действительно было так, что Safari не мог обработать эту дату (в отличие от не разбора нестандартной строки, которую вы дали ей надежно), это был бы удивительный SafariошибкаИз раздела 15.9.1.1 спецификации :

Время измеряется в ECMAScript в миллисекундах с 1 января 1970 года по UTC.В значениях времени високосные секунды игнорируются.Предполагается, что есть ровно 86 400 000 миллисекунд в день.Числовые значения ECMAScript могут представлять все целые числа от –9,007,199,254,740,991 до 9,007,199,254,740,991;этого диапазона достаточно, чтобы измерить время с точностью до миллисекунды для любого момента, который находится в пределах приблизительно 285 616 лет, либо вперед, либо назад, с 1 января 1970 г. UTC.

Но, как кажется, Safari отлично справляется с этим, когда выне просите, чтобы это пошло вне трассы, очевидно, проблема в коде синтаксического анализа для нестандартных строк.

...