Basil A. SidorovЕсть два способа привести мировое время к местному:
...
но любой вариант позволяет серверу вести все расчёты "по времени клиента", вне зависимости от собственного часового пояса .
Это справедливо в том случае, если хранить в БД время в UTC.
Но если для моего случая хранить время в UTC, то я лишаюсь возможности формировать отчетные данные (суточные реестры) средствами сервера. Вернее возможность такая по прежнему есть, но воспользоваться ею будет значительно сложнее; вместо банального select ... from ... group by trunc(REQ_CLOCK, 'dd') мне нужно будет значительно усложнять запрос, приводя мировое время к часовому поясу каждой транзакции (которое может различаться даже для одного платежного агента).
Мне время учета приходит в часовом поясе агента и работать с данными мне нужно именно по этому времени и по этому часовому поясу. Поэтому чтобы избежать ненужных преобразований в UTC и обратно, лучше с данными работать в том часовом поясе, в котором они пришли.

Basil A. SidorovЕсли клиент неверно сконфигурирован, то он будет поставлять неверные исходные данные. Если искажена первичная информация, то ошибки отчётности уже малосущественны.
Не совсем так.
В цепочке обработки данных есть три участника: платежный агент (формирующий первичную информацию), платежный шлюз (скрипт, обрабатывающий первичную информацию и сохраняющий информацию в БД) и сервер БД, который эту информацию хранит.
Ответственность за правильность первичной информации лежит на платежном агенте.
А если обрабатывать данные на платежном шлюзе (приводить время к мировому), то это лишнее звено, в котором можно допустить ошибку.
Если же на платежном шлюзе время не приводить к мировому, а сохранять как есть, то искажений не будет.