PostgreSQL QT5.4 пересылка данных между двумя базами timestamp

[Примерный ученик]

Есть две базы. Данные из одной сервер через клиент посылает на другую. Время передается в виде qint64 и устанавливается через

Код:

dt.setMSecsSinceEpoch(time)

И в первой и во второй базе время timestamppz (c привязкой к зоне Москва).
В базах время правильное. Но вот в переменной dt  на 1 час меньше.
PostgreSQL 8.1

[Пантер]

Не совсем понял проблему. Ты берешь из одной БД поле, помещаешь его в QDateTime и засовываешь в другую БД этот QDateTime? Можешь немного подробнее расписать? Проблема с таймзонами это довольно частая проблема при проектировании.

[Примерный ученик]

Надо проверять, есть ли такая запись с таким же временем. А как проверять, если время пришедшей записи, приведенное к QDateTime  на данном компьютере отличается от времени, которое в базе на 1 час. Как будет на других компьютерам с другими временными зонами не проверял

[Примерный ученик]

В запросе к базе время в формате Qt::ISODate в текстовом виде отличается от реального времени, которое показывает PGAdmin на 1 час

[Пантер]

Все равно нифига не понял. Откуда приходит запись?
Вообще, если ты можешь изменить структуру БД, я преложил бы тебе хранить в ней unixtime в UTC. То есть, int32 поле, куда ты будешь вносить dt.toUtc().toSecsSinceEpoch()

[Примерный ученик]

Я так и сделал. Храню в время в милисекундах, все нормально заработало, так как и сервера и клиенты настроены на Москву.

[Примерный ученик]

Только поле int8, так как точность до милисекунд нужна

[ssoft]

Я так и сделал. Храню в время в милисекундах, все нормально заработало, так как и сервера и клиенты настроены на Москву.

А почему бы не использовать UTC? Тогда и с локальным временем и настройкой на Москву проблем не будет.

[Примерный ученик]

Требование заказчика: серверы и клиенты имеют часовой пояс Москвы

[Пантер]

Это понятно. Ты держи в базе UTC. а для вывода конвертируй и не будет тебе проблем.. А твой час это скорее всего летнее или зимнее время где-то. Не все компы имеют обновления с последней информацией о часовых поясах.

[Примерный ученик]

Это понятно. Ты держи в базе UTC. а для вывода конвертируй и не будет тебе проблем.. А твой час это скорее всего летнее или зимнее время где-то. Не все компы имеют обновления с последней информацией о часовых поясах.

Это имело бы смысл, если бы в системе не все были в одном часовом поясе.
И да, проблема в машине с Виндой, которая почему то упорно считала, что в России сейчас летнее время. Подправили

[ssoft]

Это имело бы смысл, если бы в системе не все были в одном часовом поясе.
И да, проблема в машине с Виндой, которая почему то упорно считала, что в России сейчас летнее время. Подправили

И все-таки стоит прислушаться к опыту других). Храните все в UTC и будет счастье.
Это никак не нарушает желания заказчика и не доставляет лишних проблем для разработчика.

[Примерный ученик]

На самом деле без разницы, в каком часовом поясе хранить время. Главное ЗНАТЬ И ВВОДИТЬ поправку к текущему поясу.

[Пантер]

Нуу, не совсем... Врем на компе могут менять. Опять же, переход на зимнее или летнее... Вот узнай потом какое время было на компе год назад когда добавляли запись. А если хранить в UTC то становится пофиг на это вот все.

[Примерный ученик]

актуальность данных максимум неделя, все серверы синхронизируются по NTP от ведущего сервера. Ну а на будущее, согласен, Гринвич рулит.