Комментарии 15
Снова получил эту проблему(после хрома), но в файрфоксе (при чем в некоторых местах получались эпичные ошибки).
День работал над переопределением конструктора Date, но полностью полечить не удалось.
Вчера вечером использовал Ваше решение.
Пока полет нормальный. Все работает. Если появятся проблемы — обязательно отпишусь.
День работал над переопределением конструктора Date, но полностью полечить не удалось.
Вчера вечером использовал Ваше решение.
Пока полет нормальный. Все работает. Если появятся проблемы — обязательно отпишусь.
Кстати, дата в форматах
Будут отличаться. Причем второй вариант выдает правильную дату. А вот первый делает сдвиг и показывает нам 6 января. Впрочем как и
Это я говорю про Firefox (все сборки. последняя версия, винда и MacOS)
new Date("01/07/2015")
// и
new Date("2015-01-07")
Будут отличаться. Причем второй вариант выдает правильную дату. А вот первый делает сдвиг и показывает нам 6 января. Впрочем как и
new Date(2015, 0, 7)
Это я говорю про Firefox (все сборки. последняя версия, винда и MacOS)
Спасибо за отзывы.
Да, переопределенный метод Date.parse не работает с ISO8601.
Я не проверял работу в Firefox — тоже поправлю.
Да, переопределенный метод Date.parse не работает с ISO8601.
Я не проверял работу в Firefox — тоже поправлю.
Добавил поддержку формата ISO8601, но если вы используете библиотеку es5-shim.js, то, как выяснилось, rtz2fix.js нужно грузить после неё — иначе сломается эта самая поддержка.
Проверил в Firefox:
дают одинаковый результат при преобразовании к строке: «Wed Jul 1 2015 04:00:00 UTC+0400»
new Date(«01/07/2015»).toString() == «Wed Jan 7 2015 00:00:00 UTC+0400»
Есть один ньюанс c консолью в Firefox: на команду new Date(«01/07/2015») вы увидите Date 2015-01-07T00:00:00.000Z,
что не соответствует действительности.
На самом деле:
Просто Firefox не вызывает переопределенный метод toString(), а использует старый.
Также хотел обратить ваше внимание на то, что в результате данного патча меняется представление даты в виде числа, что может привести к определенным сложностям:
Теперь, чтобы попасть на нулевое смещение по UTC нужно выполнить такой код:
За всё приходится чем-то платить.
Проверил в Firefox:
new Date("01/07/2015 GMT+0000").toString()
// и
new Date("2015-01-07").toString()
// и
new Date("2015-01-07Z").toString()
дают одинаковый результат при преобразовании к строке: «Wed Jul 1 2015 04:00:00 UTC+0400»
new Date(«01/07/2015»).toString() == «Wed Jan 7 2015 00:00:00 UTC+0400»
Есть один ньюанс c консолью в Firefox: на команду new Date(«01/07/2015») вы увидите Date 2015-01-07T00:00:00.000Z,
что не соответствует действительности.
На самом деле:
new Date("01/07/2015").getUTCHours() == 0;
new Date("01/07/2015").getUTCHours() == 20;
Просто Firefox не вызывает переопределенный метод toString(), а использует старый.
Также хотел обратить ваше внимание на то, что в результате данного патча меняется представление даты в виде числа, что может привести к определенным сложностям:
new Date(0).toString() == "Thu Jan 1 1970 00:00:00 UTC+0300"
new Date(0).toUTCString() = "Wed Dec 31 1969 21:00:00 UTC"
Теперь, чтобы попасть на нулевое смещение по UTC нужно выполнить такой код:
new Date(-new Date(0).getTimezoneOffset()*60000).toUTCString() == "Thu Jan 1 1970 00:00:00 UTC"
За всё приходится чем-то платить.
У вас не учтен — или я не понял логики, по которой учтен — сценарий, когда единственным аргументом конструктора Date выступает дата же (это совершенно допустимый сценарий). Мы в это въехали, попробовав применить ваш код у себя в приложении с использованием телериковских компонентов. В итоге сделали маленький патчик, с ним пока вроде работает. До завтра подождем побочных эффектов, если не будет — кину pull request.
Если кому-то ещё интересно, то решение было доработано (статью тоже отредактировал) — теперь методы setTime, getTime и valueOf тоже переопределены, чтобы обеспечить прозрачную работу с нулевым смещением относительно 01-01-1970 00:00 UTC, т.е. условие
Я надеюсь, что теперь это решение вообще должно стать незаметным для разработчика.
+new Date(0) == 0
, вопреки предыдущим комментариям, теперь верно.Я надеюсь, что теперь это решение вообще должно стать незаметным для разработчика.
Большое Вам человеческое спасибо! Вы спасли мое рождество (:
Актуален ли фикс сегодня? Стоит ли держать его в проекте по сей день?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Решение проблем с RTZ2 после Microsoft Update KB2998527