Pull to refresh

Comments 15

Снова получил эту проблему(после хрома), но в файрфоксе (при чем в некоторых местах получались эпичные ошибки).
День работал над переопределением конструктора Date, но полностью полечить не удалось.
Вчера вечером использовал Ваше решение.
Пока полет нормальный. Все работает. Если появятся проблемы — обязательно отпишусь.
Кстати, дата в форматах

new Date("01/07/2015") 
//  и
new Date("2015-01-07")


Будут отличаться. Причем второй вариант выдает правильную дату. А вот первый делает сдвиг и показывает нам 6 января. Впрочем как и

new Date(2015, 0, 7)


Это я говорю про Firefox (все сборки. последняя версия, винда и MacOS)
Кстати да, возникает ошибка
new Date("2015-01-07")
Invalid Date
Спасибо за отзывы.
Да, переопределенный метод Date.parse не работает с ISO8601.
Я не проверял работу в Firefox — тоже поправлю.
Добавил поддержку формата ISO8601, но если вы используете библиотеку es5-shim.js, то, как выяснилось, rtz2fix.js нужно грузить после неё — иначе сломается эта самая поддержка.

Проверил в 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"


За всё приходится чем-то платить.
На данный момент new Date(«2015-01-07Z») — работает неверно, буду разбираться.
Похоже только Chrome понимает строку: «2015-01-07Z» — так что буду считать это недопустимым форматом и прошу игнорировать её в первом комментарии.
С консолью в Firefox всё хорошо. Видимо я уже устал и не на консоль посмотрел.
У вас не учтен — или я не понял логики, по которой учтен — сценарий, когда единственным аргументом конструктора Date выступает дата же (это совершенно допустимый сценарий). Мы в это въехали, попробовав применить ваш код у себя в приложении с использованием телериковских компонентов. В итоге сделали маленький патчик, с ним пока вроде работает. До завтра подождем побочных эффектов, если не будет — кину pull request.
По идее, в этом случае должен выполниться код new NativeDate(Y), где Y будет иметь тип Date т.е. уже исправленный объект. Вроде работало. Жду pull request, чтобы понять в чем проблема.
Дома на Win8 ни в одном браузере патч не требуется — проверить сейчас не могу.
У нас, по крайней мере, при оригинальном использовании на каждом создании дата съезжала на 3 часа (как раз разница до GMT) назад. PR завтра пришлю.
Спасибо. Проблема локализована. Повторилась в Firefox (в IE и Chrome работает без исправления, Safari и др. не проверял).
Если кому-то ещё интересно, то решение было доработано (статью тоже отредактировал) — теперь методы setTime, getTime и valueOf тоже переопределены, чтобы обеспечить прозрачную работу с нулевым смещением относительно 01-01-1970 00:00 UTC, т.е. условие
+new Date(0) == 0
, вопреки предыдущим комментариям, теперь верно.
Я надеюсь, что теперь это решение вообще должно стать незаметным для разработчика.
Большое Вам человеческое спасибо! Вы спасли мое рождество (:
Актуален ли фикс сегодня? Стоит ли держать его в проекте по сей день?
Sign up to leave a comment.

Articles

Change theme settings