См. habrahabr.ru/post/173693/#comment_6036635 Можно просто реализовать метод, который будет возвращать дату-время с игнорированием timezonedb изменений.

А не проще ли было для одного такого случая модификации даты-времени с сохранением попраки на оригинальный часовой пояс просто реализовать метод модификации, который бы автоматически корректировал время на разницу в timezonedb нужного часового пояса?

Там ведь делов то на несколько строчек :) И не пришлось бы с заморачиваться с хранением timezone каждой даты.

Это всё имеет смысл только при том, что у вас частенько возникают конвертации типа +13 years и вы хотите в таких конвертациях сохранять неизменность времени. И мало того, что это спорный вопрос насколько правильно сохранять время при конвертации в другие timezenedb правила, так ещё и сам кейс крайне крайне редкий.

Лично я не готов был бы пойти на заморочки с отдельным хранение timezone для каждой даты-времени лишь ради такого сомнительного выигрыша как сохранении времени в таких крайне редких случаях как +13 years.

Отлично, timezonedb хранит историю изменений — это здорово. И это в очередной раз доказывает, что нет необходимости хранить даты в оригинальном timezone с timezone меткой — это ничего не даёт.

$date = new DateTime('2000-01-01 12:00:00', new DateTimeZone('Europe/Moscow'));
echo $date->format('Y-m-d H:i:s P') . PHP_EOL; // 2000-01-01 12:00:00 +03:00
$date->setTimeZone(new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:s P') . PHP_EOL; // 2000-01-01 09:00:00 +00:00
$date->setTimeZone(new DateTimeZone('Europe/Moscow'));
echo $date->format('Y-m-d H:i:s P') . PHP_EOL; // 2000-01-01 12:00:00 +03:00

Как видите при конвертации Msk-UTC-Msk ничего не теряется. У вас время теряется только после того как вы 13 лет прибавляете. Не понятно только зачем вы это делаете и почему думаете, что время в 2000-ом должно быть эквивалентно времени в 2013, в то время как правила его исчисления изменились?

> Лучше Dater_Locale::getByCode('ru');

Не могу согласиться. Всё-таки Dater_Locale это класс сущности локали, а не агрегатор какой-то функциональности. А то так будет странно выглядеть Dater_Localer_English::getByCode('ru'). Ну и возможность переопределить список локалей в под-классе сущности выглядит странно. Pull реквест получил, спасибо :) но вынужден отклонить.

> timezonedb хранит не только текущие значения для разных часовых поясов, но и всю историю

Я вот тоже первым делом на это понадеился, но перепроверив понял, что это не так:

echo $dater->format('2001-07-07 12:00:00', 'time', 'UTC', 'Europe/Moscow') . PHP_EOL;
echo $dater->format('2012-07-07 12:00:00', 'time', 'UTC', 'Europe/Moscow') . PHP_EOL;

Всегда выводит 11:00. При том, что timezone_version_get() возвращает 2011.8, т.е. вполне актуальная.
Можете привести пример подтверждающий ваши слова?

Добавил статический метод Dater::getLocaleByCode('ru');

И всё равно я не пойму: если мы приводим дату-время к UTC в момент получения этой даты, то даже если в timezonedb обратная конвертация изменится, то мы всё равно получим оригинальное время. Например:

до 2008
Europe/Moscow: +4 летом

после 2008
Europe/Moscow: +3 летом

И вот к примеру летом 2007-го мы получаем datetime по UTC +4, к примеру 14:00, при водим к UTC получаем 10:00.
Потом в 2009 году обновляем timezonedb и приводим обратно эту дату-время к Europe/Moscow. И получаем уже не 14:00, а 13:00. И вы считаете это ошибкой?

На мой взгляд это очень даже правильно. Т.к. хоть для одной страны мы и получили разницу в смещении(хотя не факт что не оправданную, раз они в timezonedb изменения внесли), но для всех других стран эта метка времени осталась актуальной. А если придерживаться вашей идеии хранить название оригинальногого timezone, то потом приводя эту дату к другим часовым вы будете получать искажённое значение. К примеру будете 14:00 приводить к UTC после 2008-го и получите не 10:00, а 11:00, и так для всех других часовых поясов.

В итоге дилемма такая: или вы ломаете дату для одного пояса, или ломаете её для всех остальных поясов. Логика подсказывает, что большую погрешность в актуальности даты даёт как раз ваш, последний случай.

Кстати, в пользу хранения даты-времени у универсальном часовом поясе даже специальный тип данных ввели — timestamp называется.

Таки в одной России 9 часовых поясов :D С вероятностью 1 к 9 часовой пояс определять?))

Нет такого :)

А что существуют такие заголовки?) Расскажите? Очень интересно)

Всё будет!

Так это всё благодаря идиотам-политикам(типа Медведева), которые внезапно летнее время то отменяют, то не отменяют. В реальности же такие изменения в базах часовых поясов крайне редко происходят. И что ради этих крайне маловероятных событий теперь париться datetime в строковом формате хранить или заводить дополнительное поле для timezone? Лично мне это кажется немножко избыточными жертвами.

Плюс ко всему изменения утверждённые в гос реестре ещё неизвестно когда будут синхронизированы с базами серверов во всём Мире. Т.е. с уверенность могу сказать, что для большинства PHP серверов Россия переход на лентнее время не отменяла :) Это случится только после того как они в принудительном порядке timezonedb у себя внезапно зачемто обновят.

Всё равно не понял. Вот код преобразования из Europe/Minsk в UTC и обратно. Ничего нигде не теряется.

$dater = new Dater(new Dater_Locale_Russian(), 'Europe/Moscow');
$utcDateTime = $dater->format('2012-08-12 12:00:00', 'server_datetime', 'UTC', 'Europe/Minsk');
echo $dater->format($utcDateTime, 'server_datetime', 'Europe/Minsk', 'UTC');

Можете привести пример кода в котором что-то куда-то потеряется?

Формат данных и часовой пояс — разные вещи) Тут спросили про формат данных, datetime или timestamp. То, что часовой пояс UTC наиболее универсален для сервера трудно поспорить :)

И хранить даты нужно с уканаием пояса. Иначе вы не сможете вернуться в нужный часовой пояс и реальное время, к примеру кода у нас прыгали пояса, или между летним и зимнем временем.

Не совсем понял. Почему мы не сможем вернуться в нужный часовой пояс? Есть datetime клиента по Europe/Minsk скажем в летний период, приводим её к UTC, потом обратно в Europe/Minsk… и что вы хотите сказать, что в разное время года оно будет отличаться от исходного?

А что разве удобней вызывать date('Y-m-d H:i:s') каждый раз прописывая формат, чем просто serverDateTime()? Этот метод введён из соображений практичности, а не функциональности)

Я сторонник идеи сохранять и получать данные из базы в одом часовом поясе, так что timestamp для меня никаких особых преимуществ не даёт. Поэтому храню в datetime. timestamp использую только в MySQL(т.к. MySQL на выходе всё равно timestamp в datetime конвертирует) для полей, в которых нужно чтобы он автоматом проставлялся при ON CREATE & ON UPDATE.

Кстати говоря, оригинальное расширение уже вернули обратно в WebStore. Наверное стоит упомянуть об этом в UPD топика?

В исходниках этого расширения было сказано, что они опубликованы под BSD лицензией, так что я перезалил их в Google WebStore под новым названием RSS Subscription Helper. Надеюсь, что не забанят :) Пользуемся дальше!

Кому надо, я тут слил и расшарил исходник этого самого расширения.