В прошедшее воскресенье был осуществлен переход на летнее время – часы перевели на час вперед. Соответственно, в понедельник обнаружился баг :) Запланированные на 9:00MSK события стали срабатывать лишь в 10:00MSK.
Ларчик открывался просто: информация о событиях была занесена в БД еще в пятницу. Когда было зимнее время. И когда MSK отстоял от Гринвича на +3 часа. Соответственно, в БД локальное время для событий так же было сохранено в UTC со сдвигом относительно зимнего времени. При переходе на летнее время этот сдвиг не был откорректирован в БД. Поэтому события начали обрабатываться в указанное по UTC время +3 часа, тогда как в MSK было уже на час больше :(
Поскольку раньше никогда с учетом переходов на летнее/зимнее время я не сталкивался (да и вообще манипуляциями со временем и часовыми поясами заниматься приходилось крайне редко), то с размаху на грабли и наткнулся. Будет наука :)
Но стало интересно. Допустим, если разрабатывается софт для какой-то одной страны с несколькими часовыми поясами (для России или для Австралии, например), то избежать подобных накладок можно сохраняя информацию о времени события не в UTC+смещение, а относительно локального меридиана. Например, время относительно Москвы. Тогда все привязки останутся корректными при переходе с зимнего времени на летнее и обратно.
Однако что делать, если разрабатывается софт, который должен отслеживать события для пользователей из разных стран, в которых и свои часовые пояса и своя политика в отношении летнего/зимнего времени? Как тогда делается временная привязка событий?
PS. Кстати, думаю, что сейчас в российские программы может быть заложена мина замедленного действия. Переход на зимнее время, если мне не изменяет склероз, в России отменен. И уже осенью 2011 стрелки часов останутся в России на летнем времени. Т.е. при написании нового софта сейчас по этому поводу можно было бы не париться. Но ведь такой переход как отменили, так и опять введут :) Тем более, что существует мнение, что более правильно было бы как раз отменить переход на летнее время, а не отказаться от возврата к зимнему времени. А программы останутся ;)
>> то избежать подобных накладок можно сохраняя информацию о времени события не в UTC+смещение, а относительно локального меридиана.
ОтветитьУдалитьИМХА лучший вариант это хранить на сервере UTC. А клиент пусть сам делает что хочет. Едет в какой угодно часовой пояс с каким угодно временем, хоть весенним :).
Принцип простой - при хранении все даты-время в UTC. period. А локальное время - для каждого клиента считается на локальной стороне. В такой схеме всё отлично живёт пока не нужно будет сработать в 2:30 ночи в последнее воскресенье марта ;)
ОтветитьУдалить@Left и Mastro Ombroj:
ОтветитьУдалитьСпасибо! Мысль понял.
>более правильно было бы как раз отменить переход на летнее время, а не отказаться от возврата к зимнему времени.
ОтветитьУдалитьА чем аргументируется такое мнение?
@Quaker:
ОтветитьУдалитьНасколько я помню объяснение Анатолия Вассермана на этот счет, дело в том, что изначально ввели летнее время на территории СССР. Т.е. нормальным временем для нас является зимнее. И если Россия сейчас останется на летнем времени, то она будет опережать свое нормальное, астрономическое время на один час.