Насчет примера с проводками во Владике-Москве-Калининграде: timestamp_TZ вполпинка перегоняется куда угодно, хоть в timestamp, хоть в другую таймзону. Например, cast aTimeTZ as timestamp (=time_UTC + TZ_Offset) либо aTimeTZ as time zone 'MSK' (=time_UTC + 'MSK'_TZ_Offset ). Так что не вижу тут проблемы, кроме организационной: решить, как именно делать подсчет, по календарю или по общей шкале.

Basil A. SidorovХотя есть два варианта записи:
1. UTC (HTTP)
2. Местное время и смещение от UTC (электронная почта).
У обоих вариантов есть свои плюсы и минусы.
А есть третий вариант, UTC+смещение (как раз таки HTTP) - и он лишен всех минусов))
Тем, что пользователь тычет в правый нижний угол экрана и на голубом глазу божится, что
время у него на компьютере правильное. И даже часовой пояс может быть правильный. И даже
автоматический переход на летнее время может быть не отключен. Но он будет упорно молчать
о том, что время он таки ручками подвёл, поскольку мнение об этом переходе у его ОСи не
совпадает с текущей линией партии.
С похожим успехом можно поменять в настройках локали разделитель десятичных на ~ и весело наблюдать, как валятся все StrToFloat без явного указания FormatSettings. В битве между гроздью проверочных условий и колхозным тюнингом ОС-ей всегда выиграет последний, ибо нездоровая фантазия юзверей безгранична

Basil A. SidorovУ любого варианта со смещением есть фундаментальный изъян: невозможно корректно сдвинуть отметку по временнОй шкале. Для такого сдвига требуется (именованный) часовой пояс. Ну и умение работать с базой часовых поясов .
Ну да, и в советах по постгресу парень так и советует. Но это вполне можно даже зашить внутрь клиентской библиотеки. По крайней мере, проблемы варианта со смещением решаемы, а в ряде случаев даже вовсе отпадают за счет неиспользования таймзон и поголовного хранения в utc. Вариант же без смещения вообще слаб без привязки к локали. Это как строка без кодировки: вроде бы что-то внутри есть, но осмысленные данные достать затруднительно.
P.S. HTTP, таки - без смещения:
Твоя правда, попутал с XML датой.

Кто-нибудь может точно сказать сколько времени будет в Москве ровно через 2 года?
Сколько будет в Лондоне сказать можно. А вот сколько будет в Москве - зависит от того будет ли через два года осуществляться перевод часов на летнее время, или нет. А это политический вопрос.
Сколько будет в Лондоне, сказать нельзя. Может, будет сдвиг тектонических плит, и UK переплывет в пояс GMT-1 :). И точно так же нельзя сказать про любую таймзону любой страны. Даже сама шкала UTC и то не является строго последовательной. Т.ч. с 100% надежностью можно рассчитывать интервалы только между датами в прошлом.
1. Хранить всё в UTC (имхо без смещения, т.е. в UTC+0).
Имхо, перебор. Хотя пока не могу придумать пример необходимости хранения смещения.
2. Уметь задавать пояс сервера
Зачем? Чтобы опять иметь гемор со сменами поясов или летним временем, как в начале топика? Да еще и плодить сущности: тут у нас в конфиге +3, вон там - +3.5, а тут +4, это типа летнее время, но зимой я забыл обновить конфиг.
3. Уметь отдавать время с сервера клиенту в удобной ему зоне. Разработчику порограммы может быть удобно:
a) Видеть всё только в зоне сервера.
б) Видеть всё только в зоне своей ОС.
в) Видеть всё в указанной самим клиентом зоне (естественно что на каждый коннект она может быть своя).
г) Иметь возможность менять рабочую зону без переконнекта.
д) Иметь возможность указывать рабочую зону для конкретного запроса.
а - Зачем?
б, в, г, д - разумеется.
4. Правильно обрабатывать запросы типа:
- ... where TimeStampField >= CURRENT_DATE(CLIENT_ZONE) -- чтобы получить записи за клиентское сегодня (клиентский пояс указывается в пункте 3)
- ... where TimeStampField >= CURRENT_DATE(SERVER_ZONE) -- чтобы получить записи за серверное сегодня (серверный пояс указывается в пункте 2)
- ... where TimeStampField >= CURRENT_DATE(+3) -- чтобы получить записи за (UTC+3)-шное сегодня.
1 - можно делать по умолчанию при получении типа timestamp (в случае, если по примеру Постгреса добавлять тип timestampTZ, а не заменять timestamp)
2 - в 3й раз, зачем?
3 - разумеется; только вот, имхо, надо заранее и жестко обрубить возможность задавать смещение числом. Потому что это сегодня +3. А завтра будет +4. А сегодня, но в соседнем городе, куда прогу перенесли на флешке, - +5.

Секретное имя пользователяИнтересно еще рассмотреть вариант, когда мы сегодня записали время UTC, завтра попросили у сервера, передав ему смещение. Всё хорошо. Через некоторое кол-во лет наш часовой пояс сменился. Мы снова попросили данные за тот период, передав уже новое смещение и получили фигню-с. Впрочем, это проблемы клиента, пусть записывает и UTC, и локальное время, если ему нужны запросы по локальному.
Именно поэтому базы таймзон хранят не только текущее состояние, но и всю историю изменений. И именно поэтому зашивать в запрос константное смещение - опасно.