Tuesday, September 10, 2013

Перевод часов

Начало тут Балаган с отменой летнего времени в Израиле 2013

В этом посте я коснусь чуть подробнее вопроса как именно происходит переход с\на летнее время на компьютере (персональном, сматрфоне и т.п.). Для простоты я буду писать о сматрфоне, но все сказанное ниже в равной степени относится и к любому другому компьютеру. Маленькое замечание, многие у кого есть сматрфон ставят будильник именно в нём.
Многие были удивлены тем, что проспали на работу. "Как же"-говорили они,-"мой часы автоматически синхронизируются [с провайдером], почему же они были переведены на час назад? [и я проспал на работу]"

Краткий ответ состоит в том, что синхронизирует точное значение времени, но не его интерпретация. Часовой пояс (Timezone, типа GMT+2) оказался разный у провайдера и у вас. Провайдер не поменял часовой пояс, по новому закону, а ваш сотовый поменял, потому что в неё была "зашита" старая дата перевода часов. Таким образом одно и то же значение времени, провайдер подразумевал "старое" (без перевода) значение, а ваш аппарат "интерпретировал" как "новое".

Счастливчики, у которых последние модели, не испытывали никаких неудобств, так как у них уже "прошили" правильные даты перехода. Те у кого, обычные сотовые телефоны, также не испытали никаких проблем, так как у сотовых операторов есть технология, которая позволяет удалённо менять их настройки. Если же у вас, к примеру, iPhone, купленный в 2012 году, до смены даты перевода часов, то никто, кроме вас, изменить часовой пояс не может. В случае с персональными компьютерами, на которых стоит Windows, это делается в процессе обычных Windows Update. Так, месяца два назад в Microsoft выпустила такой update. Все, кто регулярно обновляются, не имели никаких проблем с не переводом на "зимнее" время. :-)

Если вы поняли, что я имел в виду, то дальше можно не читать. :-)

Ниже есть продолжение.

Первое, что нужно понять, что "синхронизация" времени почти всегда производится через передачу некоторого численного значения. К примеру, количество миллисекунд, которое прошло с 1 января 1970 года. Т.е. если мы хотим, чтобы на двух устройствах было одно и то же время, мы с одного устройства передаем, скажем 1384002195848 и во-втором устройстве мы меняем время на это значение. При таком способе передаче существенно то, что оба устройства находятся в одном и то же часовом поясе (Timezone). Например, если синхронизирующие передающие устройство находится в Гринвиче (GMT) и передаёт 1384002195848 то с его точки зрения это означает 09 ноября 2013 года 13:03:15 (ровно столько миллисекунд пройдёт к тому времени с 1 января 1970 года). Если же принимающие устройство находится в Израиле (GMT+2, в это время уже никто в мире, насколько мне известно, не пользуется летним временем), то с учётом смещения в 2 часа Израиля относительно Гринвича, получим 09 ноября 2013 года 15:03:15. Т.е. если у принимающего устройства часовой пояс отличается от передающего, то он "правильное" значение "неправильно" проинтерпретирует.

Таким образом, синхронизации точного времени недостаточно, нужно знать также когда меняется часовой пояс. Можно смотреть на перевод на летнее время и обратно как смену часового пояса. Возникает вопрос, а откуда принимающие устройство (компьютер дома, сматрфон и т.п.) знает в каком часовом поясе оно находится или точнее, когда в этом месте переходят на летнее время и обратно? С точки зрения производителей, часовые пояса никогда не меняются. Также, с их точки зрения, не меняются и правила перехода на летнее время...

Сделаем небольшую паузу. Итак, мы поняли, что помимо установки точного значения времени, принимающие устройство должно знать в каком Timezone оно должно быть "интепретировано". Если наш компьютер или смартфон находиться в Израиле, то это GMT+2 зимой и эффективно GMT+3 летом. Как же наше устройство знает летнее сейчас время или нет? В Израиле ситуация усложнялась ещё и тем, что отмена летнего время была по еврейскому календарю... Однако, и в других странах это "плавающая" дата, при этом правила её установления отличаются от места к месту. К примеру, США и Европа, обычно переводят стрелки часов, с разницей в неделю-две. Проще всего, таким образом, просчитать эти даты перехода, скажем, на 50 лет вперёд и "зашить" их в компьютер. Большинство производителей так и делают, "зашивают" такую таблицу.

Всё хорошо, но что происходит, когда правила определения перехода с/на летнее время меняются? "Кто-то" должен "перепрошить" таблицу перевода часов. Если этого не сделать, то даже, имея автоматическую синхронизацию времени, мы получим на выходе неправильное время. Ведь передают нам по летнему времени, а наше устройство, в соответствии со своей таблицей интерпретирует его по "зимнему".

UPDATE: 11-09-2013: Несколько маленьких замечаний.
1. Существенно, что в приведенной выше модели синхронизация происходит посредством односторонней связи передатчик->приёмник. На практике, применяется UDP broadcast. Такая архитектура существенно эффективней двусторонней связи. Таким образом следующие гипотетическое решение не работает: Устройство передаёт свой часовой пояс, и синхронизатор посылает время в его часовом поясе. Усложнение связи не оправдано ведь 99% это лишний overhead.

2. В описании выше я говорил, что у приёмника и передатчика должна быть один и тот же часовой пояс. Строго говоря, можно несколько ослабить это требование, достаточно, чтобы приёмник знал в каком часовом поясе было послано значение времени и чтобы его собственный часовой пояс был верен. Он может его затем сам привести со своим часовом поясом. Проблема в том, что в этом случае нужно строить механизм синхронизации часового пояса в дополнении к синхронизации времени. Задача ещё осложняется и тем, что для этого нужно знать географическое положение компьюетра. Для персонального компьютера это уже не тривиально (определение по IP лишь эвристика), смартфон может воспользоваться GPS, но для GPS важно точно замерять время...

3. А что будет, если вместе с численным значением передать часовой пояс передатчика? Тогда приёмник будет знать точное время, однако если у него неправильно определён time zone, то пользователь увидит "неправильное" время.

4. Ну и замечание общего плана. Если бы перевод часов осуществлялся бы каждый день, то за несколько дней этот механизм давно был бы отлажен. Тогда, к примеру, было бы оправданным создавать инфраструктуру по синхронизации time zone. Однако, перевод часов осуществляется дважды в год, при чём обычно он проходит относительно гладко. Поэтому и возникают ситуации, когда перевод часов даёт сбои.
END OF UPDATE