Comments 69
Вангую, что команда разработчиков Хрома добавит еще один regression-тест :)
Пост закончился внезапно. После «зачастую ошибаются и показывают неверные даты» ожидал увидеть ещё текст, но его не было
Все закончилось хорошо. Ошибка (на сайте) поправлена, рождество (не везде, конечно) спасено, тестировщики довольны.
Вспомнился мультик, где «рождество отменено и всё это из-за мальчика по имени Джимми Нейтрон» (на 12:13) ( vk.com/video?q=%D0%B4%D0%B6%D0%B8%D0%BC%D0%BC%D0%B8%20%D0%BD%D0%B5%D0%B9%D1%82%D1%80%D0%BE%D0%BD%20%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D1%81%D1%82%D0%B2%D0%BE§ion=search )
Как поправили-то?
В своем коде, где нужны были только даты — добавил три лишних часа. Даты остались датами, но теперь правильными.
Сторонний код править зачастую себе дороже, поэтому для jQueryUI календаря не правил ничего, там и проблема ближайшая в 2020 году.
Сторонний код править зачастую себе дороже, поэтому для jQueryUI календаря не правил ничего, там и проблема ближайшая в 2020 году.
Спасибо!
Какой веселый костыль) Ну, а комментарий оставили, почему так сделали? Чтоб потом никто не матерился: «Какой му*ак тут прибавляет к датам 3 часа?».
Всё же надеюсь, что MS выпустит какой-то другой патч, исправляющий эту ошибку.
Какой веселый костыль) Ну, а комментарий оставили, почему так сделали? Чтоб потом никто не матерился: «Какой му*ак тут прибавляет к датам 3 часа?».
Всё же надеюсь, что MS выпустит какой-то другой патч, исправляющий эту ошибку.
Да, оставил todo: «проверить в новых версиях и удалить за ненадобностью».
написал сегодня похожее сообщение, пока не стал удалять, так как в нем указал возможное решение.
Календарь в jquery ui я исправил следующим образом:
— если старая версия, то необходимо поменять функцию
Без данного исправления декабрь 2013 состоял из 1 дня (тут украли не то что рождество, а целый месяц). В актуальных версиях эта функция работает правильно.
Кроме того, необходимо изменить функцию вычисления дня недели первого дня месяца, добавив к дате хотя бы 1 час (4-й аргумент):
И это не проблема 2020 года. Без данного исправления неправильно отображается уже январь 2014 — как будто он начался во вторник.
Проблема с датами в хроме (в ближайшем обновлении будет исправлена) и в эксплорере. После указанного исправления календарь везде работает нормально.
Календарь в jquery ui я исправил следующим образом:
— если старая версия, то необходимо поменять функцию
/* Find the number of days in a given month. */
_getDaysInMonth: function(year, month) {
return new Date(year, month+1, 0).getDate();
},
Без данного исправления декабрь 2013 состоял из 1 дня (тут украли не то что рождество, а целый месяц). В актуальных версиях эта функция работает правильно.
Кроме того, необходимо изменить функцию вычисления дня недели первого дня месяца, добавив к дате хотя бы 1 час (4-й аргумент):
/* Find the day of the week of the first of a month. */
_getFirstDayOfMonth: function(year, month) {
return new Date(year, month, 1, 1).getDay();
},
И это не проблема 2020 года. Без данного исправления неправильно отображается уже январь 2014 — как будто он начался во вторник.
Проблема с датами в хроме (в ближайшем обновлении будет исправлена) и в эксплорере. После указанного исправления календарь везде работает нормально.
Если погулять по ссылкам, то можно много интересного накопать: в Сан-Паулу пропало 18е октября (как следствие в Chrome canary всё уже пофикшено), Сиднее пропало 6е октября (правда это уже в Safari), заметки с iPhone пропадают…
Каким местом это всё писалось, интересно, что такой фееричный результат достигнут?
Каким местом это всё писалось, интересно, что такой фееричный результат достигнут?
Просто даты такая сумрачная материя, что только кристально чистые адепты могут не натворить в ней делов.
А поскольку таких нет, и все мы люди и иногда ошибаемся, то и получается такой результат.
На эту тему есть отличный сборник заблуждений: habrahabr.ru/post/146109/
А поскольку таких нет, и все мы люди и иногда ошибаемся, то и получается такой результат.
На эту тему есть отличный сборник заблуждений: habrahabr.ru/post/146109/
Ещё в копилку: OpenOffice.org won’t print on Tuesdays.
Только ли в хроме дело?
Буквально вчера в FireFox наблюдал занятный эффект в календаре на главной странице одного сайта — смещение дат на 1 день назад. Эффект действует до 7-го января включительно.

Буквально вчера в FireFox наблюдал занятный эффект в календаре на главной странице одного сайта — смещение дат на 1 день назад. Эффект действует до 7-го января включительно.

Хотя строго говоря, это не проблема браузера(-ов).
Браузеры опираются на API OS и просто транслируют все чудеса, которые были принесены кривым обновлением.
Браузеры опираются на API OS и просто транслируют все чудеса, которые были принесены кривым обновлением.
Тогда почему сломалось не везде?
Думаю, что некоторые реализации опираются на иные источники данных о часовых поясах (например на tz database). Но даже в этом случае не факт, что всё хорошо — как минимум текущая дата/время предоставляется операционкой. Принцип GIGO никто не отменял.
А как вы объясните то, что в Хроме в зоне -3 (Бразилия) тоже есть баг:
даже без обновления KB2998527 Винды!
new Date("October 19, 2014");//Sat Oct 18 2014 23:00:00 GMT-0300
даже без обновления KB2998527 Винды!
Разные причины ошибок.
То о чём вы говорите, похоже, решено в этом фиксе: diff/1/src/date.h. И конкретно это — ошибка разработчиков браузера (в DaylightSavingsOffsetInMs нужно передавать локальное время, а они передали UTC).
Однако обратите внимание на функцию GetLocalOffsetFromOS — она берёт смещение локального времени у ОС.
virtual int GetLocalOffsetFromOS() {
double offset = base::OS::LocalTimeOffset(tz_cache_);
DCHECK(offset < kInvalidLocalOffsetInMs);
return static_cast(offset);
}
Т.е. хром использует базу часовых поясов операционки и это является причиной обсуждаемой проблемы с KB2998527.
<лирика>
Если у вас есть подвесной мост, то он может упасть по различным причинам — отвалится либо один конец, либо второй (или оба) — тут аналогичный случай.
</лирика>
То о чём вы говорите, похоже, решено в этом фиксе: diff/1/src/date.h. И конкретно это — ошибка разработчиков браузера (в DaylightSavingsOffsetInMs нужно передавать локальное время, а они передали UTC).
Однако обратите внимание на функцию GetLocalOffsetFromOS — она берёт смещение локального времени у ОС.
virtual int GetLocalOffsetFromOS() {
double offset = base::OS::LocalTimeOffset(tz_cache_);
DCHECK(offset < kInvalidLocalOffsetInMs);
return static_cast(offset);
}
Т.е. хром использует базу часовых поясов операционки и это является причиной обсуждаемой проблемы с KB2998527.
<лирика>
Если у вас есть подвесной мост, то он может упасть по различным причинам — отвалится либо один конец, либо второй (или оба) — тут аналогичный случай.
</лирика>
То о чём вы говорите, похоже, решено в этом фиксе: diff/1/src/date.h.
Можете объяснить смысл исправления? Я уже с десяток раз пытаюсь понять разницу между
time_ms += LocalOffsetInMs();
return time_ms + DaylightSavingsOffsetInMs(time_ms);
иreturn time_ms + LocalOffsetInMs() + DaylightSavingsOffsetInMs(time_ms);
Вот так: https://bugzilla.mozilla.org/show_bug.cgi?id=1074821
Но я уже понял (я писал этот тикет) что FF ведет себя правильно полностью соответствуя тому, что ему говорит ОС. А вот в Chrome есть другой баг https://code.google.com/p/v8/issues/detail?id=3116 который и привел к вылетанию часа 2014.01.01.
Не факт, но возможно что каждая первая среда года вылетает по той же причине
Но я уже понял (я писал этот тикет) что FF ведет себя правильно полностью соответствуя тому, что ему говорит ОС. А вот в Chrome есть другой баг https://code.google.com/p/v8/issues/detail?id=3116 который и привел к вылетанию часа 2014.01.01.
Не факт, но возможно что каждая первая среда года вылетает по той же причине
там написано, что Файрфокс добавляет час.
«И тут откуда-то выползает мой тестировщик, без Рождества. Ему больно! Но он подползает и говорит мне:
— Разработчииииик! Я Рождества не чувствую…
А я ему:
— А у тебя его нет!»

— Разработчииииик! Я Рождества не чувствую…
А я ему:
— А у тебя его нет!»

У меня из-за этой же причины разворотило графики amCharts:

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

Как лечить не придумал, кроме как заменить часовой пояс в системе.
Долго не мог понять, что автор тестирует и на что жалуется, пока не понял, что речь про православное рождество. Первым в голову почему-то пришло католическое
Наверное, потому, что недели в календаре оканчиваются субботою, а это принято в Новом свете и в Юго-Восточной Азии, где юлианский календарь («православное рождество»), наоборот, не в обычае. Вот карта, на которой синим отмечены те страны, где неделя оканчивается субботою, жёлтым — где воскресеньем, а зелёным — где пятницею:
![смотреть на Викискладе [карта]](https://upload.wikimedia.org/wikipedia/commons/e/e2/First_Day_of_Week_World_Map.svg)
При этом и воскресное начало недели, и юлианский календарь по сути относятся к культурному наследию тысячелетней жизни православного государства Восточной Римской Империи (которая, в свою очередь, почерпнула их из более древних источников). Просто наследство это неравномерно распределено.
По карте также ясно, что день окончания недели может иметь и вероисповедное значение: видно, например, что пятничное окончание недели принято в исламских странах, а субботнее — в Государстве Израиль (и в США, где евреев не меньше).
При этом и воскресное начало недели, и юлианский календарь по сути относятся к культурному наследию тысячелетней жизни православного государства Восточной Римской Империи (которая, в свою очередь, почерпнула их из более древних источников). Просто наследство это неравномерно распределено.
По карте также ясно, что день окончания недели может иметь и вероисповедное значение: видно, например, что пятничное окончание недели принято в исламских странах, а субботнее — в Государстве Израиль (и в США, где евреев не меньше).
А в странах, отмеченных серым цветом в какой день неделя начинается?
А в Китае тоже много евреев?
Поставил апдейт от майкрософта, теперь тоже нет Рождества(
new Date(2015, 0, 7);
Tue Jan 06 2015 23:00:00 GMT+0500 (Russia TZ 4 Standard Time)
Это вывод по умолчанию в UTC формате, сделай преобразование
.toString()
хотя бы.автор топика
.toString()
не вызывал, поэтому я поступил аналогичноТогда соблюдайте аналогию полностью и для проверки вызывайте
.getDate()
ведь это важнее, чем просто созданный объект. У вас не ошибка, создайте любую Date
и получите на день меньше.У меня нет апдейта винды
У меня тоже не ошибка?
>>и для проверки вызывайте .getDate()
>>создайте любую Date и получите на день меньше.
что-то я не получаю на день меньше
new Date(2015, 0, 7);
Wed Jan 07 2015 00:00:00 GMT+0400 (Russian Standard Time)
У меня тоже не ошибка?
>>и для проверки вызывайте .getDate()
>>создайте любую Date и получите на день меньше.
var d = new Date(2015, 0, 7);
d.getDate();//7
var d = new Date(2015, 10, 7);
d.getDate();//7
что-то я не получаю на день меньше
И у вас и у Рината всё норм. Вообще представление объекта Date может быть каким угодно в отладчике, поэтому преставления в виде вывода консоли не корректны (т.е. первая вставка кода, а вот со второй всё норм)) Потому что:
Даже если там напишет «На день раньше четверга в месяц, что идёт перед високосным, год являющийся разницей двойки в 11-ой степени и 33, время выхода Бетмена на охоту, т.е. полночь ровно» это будет корректно) Интересно именно что
Хех, даже в своих багах винь не постоянна)
Даже если там напишет «На день раньше четверга в месяц, что идёт перед високосным, год являющийся разницей двойки в 11-ой степени и 33, время выхода Бетмена на охоту, т.е. полночь ровно» это будет корректно) Интересно именно что
getDate()
вернёт, равно как и toString()
.Хех, даже в своих багах винь не постоянна)
вывод в консоль — это неявный вызов toString() и есть.
getDate возвращает число в месяце, а не саму дату.
всё же это ошибка, хотя бы потому, что Date(2015, 0, 7); — это локальное время, и 7 января никогда переводов часов не было
getDate возвращает число в месяце, а не саму дату.
new Date(2015, 0, 7);
Tue Jan 06 2015 23:00:00 GMT+0500 (Russia TZ 4 Standard Time)
всё же это ошибка, хотя бы потому, что Date(2015, 0, 7); — это локальное время, и 7 января никогда переводов часов не было
Вы не правы, вывод в консоль объекта это не обязательно вызов
можете проделать с датой то же самое в Firefox.
Представление объектов в отладочной консоли дело сугубо разработчика и доков контролирующих это я не встречал (хотя и просмотрел w3c доков прилично).
А вот предположить, что ошибка в указании временной зоны +5 это можно. Проверить можно вызвав
Ошибка же в представлении данных есть, но даже если числа будут в стиле хищника вряд ли можно считать её критичной. В отличии от хранимой даты.
toString
. Скажу больше, в последних версиях webkit-gekko браузерах это не так почти всегда: сравните вывод1
и (1).toString()
{}
и ({}).toString()
можете проделать с датой то же самое в Firefox.
Представление объектов в отладочной консоли дело сугубо разработчика и доков контролирующих это я не встречал (хотя и просмотрел w3c доков прилично).
А вот предположить, что ошибка в указании временной зоны +5 это можно. Проверить можно вызвав
getTimezoneOffset()
. И если он не -240 (разница между UTC и локальным временем в минутах) это будет настоящая ошибка.Ошибка же в представлении данных есть, но даже если числа будут в стиле хищника вряд ли можно считать её критичной. В отличии от хранимой даты.
Правильное решение — не использовать метку времени для описания дат. Дата должна описываться тремя числами: годом, месяцем и днём.
Когда вы пишете: new Date(2015, 0, 7);
Вы на самом деле получаете: new Date(2015, 0, 7, 0, 0, 0);
Со всеми вытекающими отсюда проблемами с часовыми поясами и тп.
Что использовать вместо Date? Например, неплохую библиотеку.
Когда вы пишете: new Date(2015, 0, 7);
Вы на самом деле получаете: new Date(2015, 0, 7, 0, 0, 0);
Со всеми вытекающими отсюда проблемами с часовыми поясами и тп.
Что использовать вместо Date? Например, неплохую библиотеку.
Вообще-то, просто нужно явно указывать часовой пояс и хранить все даты в UTC.
и повезло больше всех почему-то тестировщикам
тестировщики должны страдать.
Я бы сказал, как Windows украл рождество) Всё-таки хромы под маками и линухами в грехах не замечены)
Но почему тогда в IE11 все нормально?
Давайте заглянем в исходники IE11. Ах да, забыл, что они не опубликованы…
А если почти серьёзно, то в Chromium by Linux всё нормально, выше разбиралось, что смещение временной зоны получается через API. И по сути любой календарь работающий с данным API выдаст странность при таком же алгоритме.
И совсем доказательство: наличие исправления доказывает наличие ошибки. А значит вина за ошибку на МягкомСофте. ч.т.д.
А если почти серьёзно, то в Chromium by Linux всё нормально, выше разбиралось, что смещение временной зоны получается через API. И по сути любой календарь работающий с данным API выдаст странность при таком же алгоритме.
И совсем доказательство: наличие исправления доказывает наличие ошибки. А значит вина за ошибку на МягкомСофте. ч.т.д.
Разработчики хромиума же подтвердили наличие проблемы, и исправление уже внесено в код браузера (V8) — должно появиться в 38-ой версии
я прочитал code.google.com/p/chromium/issues/detail?id=417640 и не совсем понял, баг пофиксят в 38 и 39 версии?
Перечитайте коментарии выше — вина в неправильном вызове API
Как писали выше, ещё раз трабл: тут
Так же описанные изменения в этом комментарии.
Да, в хроме есть ошибка, но спровоцировало её выявление ошибка в Win7 update.
Так же описанные изменения в этом комментарии.
Да, в хроме есть ошибка, но спровоцировало её выявление ошибка в Win7 update.
по каким критериям вы решили, что это ошибка Винды?
По тому, что на это выпустили патч, разумеется.
Ну и не смотря на наличие бага в линухах хромиумы берут дату адекватно. Проверено.
Ну и не смотря на наличие бага в линухах хромиумы берут дату адекватно. Проверено.
Никто на это не выпускал патч в МС, это патч с изменениями в часовых поясах, а не исправление правильно работающего API.
Вызывали неправильно — да. Но это проблема хромиума.
Вызывали неправильно — да. Но это проблема хромиума.
Кто выпустил патч? Гугл?
Причем тут обновление винды тогда?
Почему Мозилла не выпускала никаких патчей, если это обновление вызывает ошибки?
Странно, что в линухе Хром работает.
Какой часовой пояс? Есть ли перевод часов?
Причем тут обновление винды тогда?
Почему Мозилла не выпускала никаких патчей, если это обновление вызывает ошибки?
Странно, что в линухе Хром работает.
Какой часовой пояс? Есть ли перевод часов?
Патчи обе конторы выпустили.
Винда патч с зимним временем, а хром с этими прибавлениями/вычитаниями.
У Мозиллы своя атмосфера, там иначе проявляется и опять таки в только в Окошках.
Ничего странного: API получения времени и смещения разное) Мог бы поискать пруф этой части, но я уже так намыкался с исходниками Хромиума, что почти уверен, что и эта часть под разные платформы с разной реализацией)
+4, есть.
Винда патч с зимним временем, а хром с этими прибавлениями/вычитаниями.
У Мозиллы своя атмосфера, там иначе проявляется и опять таки в только в Окошках.
Ничего странного: API получения времени и смещения разное) Мог бы поискать пруф этой части, но я уже так намыкался с исходниками Хромиума, что почти уверен, что и эта часть под разные платформы с разной реализацией)
+4, есть.
Микрософт выпустил патч, чтобы сделать постоянный перевод часов на +3, а не для исправления какой-либо ошибки.
Я думаю так: была ошибка в Хроме, она не проявлялась, до тех пор пока Микрософт не выпустила обновление на постоянное +3.
Микрософт выпустила обновление, ошибка в Хроме проявилась.
В Линухе никто обновление на постоянное +3 не выпускал, поэтому ошибка в Хроме осталась не замеченной.
Я думаю так: была ошибка в Хроме, она не проявлялась, до тех пор пока Микрософт не выпустила обновление на постоянное +3.
Микрософт выпустила обновление, ошибка в Хроме проявилась.
В Линухе никто обновление на постоянное +3 не выпускал, поэтому ошибка в Хроме осталась не замеченной.
Давайте заглянем в исходники IE11. Ах да, забыл, что они не опубликованы…
А зачем туда заглядывать? Проблема же в хроме. Ну в общем все понятно с вами :)
Чтобы ответить на вопрос почему в 11 осле всё хорошо. Очевидно, Ватсон!
Любому кодеру может и очевидно, но проблему надо искать у себя :)
Sign up to leave a comment.
Хром, укравший рождество