Fr0sT-BrutalКстати, мне прямо стало интересно: приведите хоть кто-нибудь живой пример, где
У меня есть платежный шлюз, который обрабатывает запросы от разных платежных агентов.
Платежный шлюз интегрируется в биллинговой системой.
Платежный шлюз и биллинговая система находятся в GMT+3.
Платежные агенты находятся где угодно.
Платежные агенты взаимодействуют с платежным шлюзом, передавая ему информацию о транзакции: идентификатор, дата и время учета платежа, дата и время проведения платежа, сумма платежа и некоторая другая информация.
Дата и время проведения платежа — это момент, когда пользователь (клиент) осуществил платеж. Дата и время учета платежа — это момент, когда процессинговый центр подтвердил транзакцию. Некоторые платежные агенты возвращают дату и время в своем часовом поясе или в часовом поясе платежного терминала, с которого осуществлялся платеж (а для крупных систем платежные терминалы находятся в разных часовых поясах). Некоторые платежные агенты возвращают дату и время в UTC. Некоторые платежные агенты для даты и времени учета платежа используют локальный часовой пояс, а для даты и времени проведения платежа используют часовой пояс платежного терминала.
Отчеты и сверки основываются на дате и времени учета платежа. В биллинговой системе дата и время всегда указываются в часовом поясе GMT+3.
Это живой пример, когда мне на сервере нужно знать часовой пояс сервера (чтобы корректно перевести в GMT+3 для биллинговой системы), часовой пояс клиента (чтобы оператор видел отчеты в местном часовом поясе) и часовой пояс удаленной системы (чтобы правильно формировать ежедневные и ежемесячные отчеты и сверки).

Время приходит не в UTC, от третьих сторон.
Поэтому от хранения часового пояса и от операций со временем не уйти.

Кроме того, есть резон хранить метки именно в том виде, в котором они пришли.
Например пришла транзакция с меткой 2015-06-02T18:56:12+0400.
А на сервере в этот момент время 2015-06-02T17:55:12+0300 (или 2015-06-02T14:55:12 в UTC).
То есть время на моем сервере и на удаленном сервере различается на минуту.
Тем не менее, учет будет осуществляться именно по удаленному времени, поэтому хранить нужно именно его.

Мне казалось, что я на русском языке написал.
Не только конфликтные ситуации, но и отчеты/сверки (суточные/месячные реестры и соответствующие суммы платежей и вознаграждений) формируются по дате и времени учета, которое передается платежным агентом. И часовой пояс в этой метке времени может быть любым. Если уж хранить в БД временную метку без часового пояса, то ее нужно сохранять в том виде, в котором она приходит, а не переводить в UTC. Но если в разных столбцах используется разный часовой пояс, то это хуже, чем не использовать его вовсе (всегда хранить в UTC или в локальном часовом поясе).

Fr0sT-BrutalСервер-то тут причем? Все, что тебе нужно знать, - это пояс биллинговой системы.
Часовой пояс сервера мне нужно знать, чтобы работать с временем платежного агента (переводить его в UTC или в пояс биллинговой системы).

Fr0sT-BrutalКстати, а зачем тебе вообще использовать время проведения? Время учета - вот что главное. А оно выставляется проц. центром, соответственно, его можно и нужно хранить в инвариантном виде.
Время проведения это информационный параметр, его можно и не использовать.
Важно именно время учета. Оно выставляется процессинговым центром.
Но процессинговые центры у разных платежных агентов разные, и часовой пояс передаваемого времени также разный. И даже у одного платежного агента теоретически могут прийти две разные транзакции с разными часовыми поясами.

То есть для получения реестра платежей предлагается забрать клиентом все транзакции, а затем делать группировку на клиенте?
Чем это лучше group by на сервере? Кроме гипотетичной сложности обработки TZ?

Basil A. SidorovЯ - о том, что клиент приводит (входящие) данные платежа к нужному виду и только после этого начинает работать с базой.
Нет, как раз об этом. Но с разных сторон.
Что подразумевается под привидением данных к нужному виду? Перевод в UTC и сохранение в БД? Но формирование реестров и сверки осуществляются по переданному времени учета в том часовом поясе, в котором время передавалось. Если мне пришла транзакция с отметкой 2015-06-04T02:00:00+05:00, то эта транзакция должна попасть в реестр от 4 июня. А если я эту отметку переведу в UTC 2015-06-03T21:00:00 и сохраню в БД, то при выполнении SQL-запроса в группировкой GROUP BY trunc(REQ_CLOCK, 'dd') эта запись будет отнесена к группе 2015-06-03.
Чтобы правильно выполнить группировку, сервер должен знать свой часовой пояс, а также часовой пояс платежного агента. Либо на клиент нужно загружать все транзакции, пересчитывать часовой пояс на клиенте и группировать также на клиенте.
Также можно сохранять в БД отметку времени в том виде, в котором она пришла, без часового пояса. То есть для приведенного ранее примера в БД будет сохранена отметка 2015-06-04T02:00:00. Для работы с платежными агентами этого будет достаточно. Но кроме платежных агентов у меня также есть биллинговая система, в которую нужно импортировать платежи, но время операции нужно перевести в часовой пояс биллинговой системы. Этот перевод в принципе тоже можно сделать на клиенте, но клиент должен знать часовой пояс платежного агента, часовой пояс платежного шлюза, часовой пояс биллинговой системы. На сервере это сделать проще, надежнее и быстрее.

Basil A. SidorovДостаточно, чтобы клиент отправил параметр, который сервер и использует в запросе.
Можно пример? Что значит «параметр», разница в часах/минутах?
Правильный учет даты и времени — это достаточно сложно . Если это делать на клиенте, то легко допустить ошибку. Лучше работу с датой и временем осуществлять на сервере БД, на котором таких ошибок не возникнет, если сервер и его окружение правильно сконфигурированы.