kdvПричем, все это означает, что часовой пояс клиента - это не просто "часовой пояс У клиента", а именно часовой пояс, который клиент сообщает серверу для получения TIMESTAMP в его локальном времени.
Причем можно даже и не сообщать, перекладывая преобразование/отображение на клиента.
kdvНапример, текущий CURRENT_TIMESTAMP предполагает, что часовой пояс клиента и сервера идентичен. И различия этих часовых поясов порождает проблемы. Но если у нас есть UTC, и у меня сервер в UK, а я сижу в Москве, и знаю свой часовой пояс, зачем мне локальное время сервера? Придумай пример :-)
++
dimitrколь пошла такая пьянка, заодно придумайте, как обеспечить совместимость :-) По стандарту CURRENT_* функции возвращают UTC. Забивать болт и делать отсебятину или ломать все?
Стандарт есть Истина, к коей стремиться надобно. Вопрос только, каких размеров гемор будет с таким breaking change. Еще один диалект - муторно, тут первый-то постоянно всплывает. Хотя сейчас есть отличная возможность приурочить всё это к трёшке, пока она еще не закаменела в релизе.
Если время на сервере хранить в UTC без тайм-зоны, то получится что владивостокские (UTC+10) 01.01.2016 09:00 равны серверному 31.12.2015 23:00.
Как выбрать документы за 1 января по владивостокскому времени? И что вернёт CURRENT_DATE для этого владивостокского времени?
Вариант совсем без таймзоны вроде как и не рассматривается, хотя приведенный пример как раз не сильно сложен в случае типа TIMESTAMP: принудительно переводить полученные от клиента TIMESTAMP из его часового пояса (заданного заранее) в UTC. Проблемы начнутся при использовании типа DATE.

Рекомендации для Постгреса, кстати, довольно толковые. И вообще, неплохая реализация сабжа без breaking change.

Dimitry SibiryakovОни начнутся ещё раньше, когда с этой бедой начнут работать пользователи на ОСях разной
степени пропатченности и самыми дикими настройками, какие в голову взбредут.

Например? Мне кажется, как раз за счет подтягивания пояса с клиента результаты могут хоть и плавать на определенную константу, но все же получить осмысленные данные при выборке between '2000-01-01 00:00:00, GMT+8.32' and '2000-01-01 01:00:00, GMT+8.32' больше, чем при between '2000-01-01 00:00:00' and '2000-01-01 01:00:00', если у клиента GMT+8.32 (мало ли какая страна так выпендрится), у сервера GMT+3, а у заполнявшего клиента GMT-9.

Т.е. мой поинт в том, что если вовлечены дико настроенные ОСи странной пропатченности - с ними и сейчас правильные результаты едва ли получишь.