Давайте рассмотрим пример с 5 октября 2014. Имеем строку «2014-10-5 12:00».
1. Парсим год: 2014
2. Создаём объект дата 01.01.2014 — получаем дату: 31.12.2013 23:00:00
3. Парсим месяц — 10 — меняем месяц в нашей дате: 31.10.2013 23:00:00
4. Парсим число — 5 — меняем число в нашей дате 5.10.2013 23:00:00
5. Парсим время — 12:00, в нашей дате 5.10.2013 12:00:00
Вот мы и год назад. Не пытаюсь оправдять Apple. Просто вариант причины такого поведения
Там алгоритм был такого плана: парсится текстовая строка с датой. Сначала берётся год — 2014, создаётся объект дата 01.01.2014 00:00:00 (new date(2014,0,1)), чтобы потом распарсить месяц, число, время и добавить в дату, а Хром вместо этого создаёт дату: 31.12.2013 23:00:00. Оп, и мы уже год назад.
А проблема на самом деле не только в iCloud, а в механизме обработки часовых поясов. Заметил такую штуку на прошлой неделе в JavaScript, разбирая такое же поведение одной библиотеки (дата на год в прошлом). А дело вот в чём: alert(new Date(2014,0,1));
выдаёт в Chrome: Tue Dec 31 2013 23:00:00 GMT+0300 (RTZ 2 (зима)), а в Firefox: Wed Jan 01 2014 01:00:00 GMT+0400 и только в IE 9 — Wed Jan 1 00:00:00 UTC+0300 2014
Причем у меня это всплыло в куске, который парсит дату в ISO8601, возможно у Apple алгоритм похож.
Спасибо нашему правительству за очередную головную боль. Кто знает, где это ещё всплывет.
В общем что мы имеем: Nexus One 2.3 кастомная (LiveView софт тоже последней версии) + LiveView (последняя прошивка). На ночь поставил на зарядку. С утра в 8:23 подключил к телефону и поехал на работу. По дороге пару раз переключал треки в плеере и игрался с громкостью. На работе поглядывал изредка, живо ли ещё. Примерно часов в 10 показывало примерно три четверти заряда. В 11:53 дивайс уже не подавал признаков жизни. Грустно это всё.
Читал, что присутствует какая-то несовместимость с broadcom-овским bluetooth стеком, который присутствует на нексусе, вызывающая обрывы соединения и как следствие — постоянные попытки реконнекта. Возможно в связке с сониевскими андройдофонами и будут эти самые 4 дня, у меня же происходит именно так, как я описал.
Дам этой штуке ещё один шанс, завтра засеку сколько продержится.
А ещё эта штука работает менее 6 часов от аккумулятора. С утра выходишь с полностью заряженным, а после обеда с удивлением замечаешь, что батарейка полностью разрядилась, и LiveView давно уже не работает.
Купил эту штуку в декабре, использовал пару раз: пару дней после покупки, и ещё раз после выхода новой прошивки устройства. Очень разочаровался в реализации. Тестировал в паре с Nexus One 2.2. Надо бы в свеженькой 2.3 ещё разок попробовать.
А вот в андройде есть такая функция, как примерное определение координат по базовым станциям и wi-fi точкам. Увеличив базу точек, увеличивают точность?
1. Парсим год: 2014
2. Создаём объект дата 01.01.2014 — получаем дату: 31.12.2013 23:00:00
3. Парсим месяц — 10 — меняем месяц в нашей дате: 31.10.2013 23:00:00
4. Парсим число — 5 — меняем число в нашей дате 5.10.2013 23:00:00
5. Парсим время — 12:00, в нашей дате 5.10.2013 12:00:00
Вот мы и год назад. Не пытаюсь оправдять Apple. Просто вариант причины такого поведения
alert(new Date(2014,0,1));выдаёт в Chrome: Tue Dec 31 2013 23:00:00 GMT+0300 (RTZ 2 (зима)), а в Firefox: Wed Jan 01 2014 01:00:00 GMT+0400 и только в IE 9 — Wed Jan 1 00:00:00 UTC+0300 2014
Причем у меня это всплыло в куске, который парсит дату в ISO8601, возможно у Apple алгоритм похож.
Спасибо нашему правительству за очередную головную боль. Кто знает, где это ещё всплывет.
Дам этой штуке ещё один шанс, завтра засеку сколько продержится.
Купил эту штуку в декабре, использовал пару раз: пару дней после покупки, и ещё раз после выхода новой прошивки устройства. Очень разочаровался в реализации. Тестировал в паре с Nexus One 2.2. Надо бы в свеженькой 2.3 ещё разок попробовать.