freepascal.ru

TRxMemoryData + ZEOS trunk + Postgresql + Laz&FPC trunk
В общем проблема с временной зоной.
Где-то с месяц наверное в FPC что-то сломали по части временных зон. Разработчик ZEOS пофиксил данную проблему через костыль.
Но я использую TRxMemoryData и через него время вообще не правильно показывает в гриде, хотя с ZEOS время прилетает правильное, но как только оно попадает в TRxMemoryData то его коверкает.
Попробовал использовать TZMemTable из пакета ZEOS - с ним время показывает правильно в Гриде, но вылетают другие ошибки под которые неохота подстраивать приложение, т.к. всем устраивал TRxMemoryData.
Прикладываю картинки для наглядности. Форма для изменения данных показывает время правильно, т.к. данные берет из объекта а не из Датасета.


Блин из-за этого косяка не могу дальше двигаться с обновлением программы. Как бельмо - мешает психологически.
Может есть у кого какие мысли

Вообще время и его варианты - это целая наука. Есть мировое, есть локальное(которое тоже может иметь градации) - пользовательское, которое настраивается из конфигурации пользователя оно может быть очень специфическим: Китайский, Японский, Еврейский, Ацтекский, Исламский и т.п.
есть системное, которое может иметь тоже разные варианты: привязанные к местному времени, синхронизирующие от гранича, или от столицы, или от региональных, от тика CPU .. и все на этой системе уже рассчитывается все что крутится

Могу предположить несколько вариантов решения, но сначала нужно разобраться с датой. В PostgresSQL есть 2 вида таймштампа timestamp without time zone (время без часового пояса) и timestamp with time zone (время с часовым поясом).
Самое простое timestamp without time zone (время без часового пояса) - время как есть без -/+ часовых поясов.
сложнее timestamp with time zone (время с часовым поясом) - это возможно время нужно "нормализовать", смотря какие задачи, например вывести отчеты за определенный общий для всех промежуток времени.

Т.е. сначала нужно узнать какое время записано.
Второе какие часы локальные часы тикают.
И следовательно кто то из TZMemTable и TRxMemoryData при выводе используя системные функции, с учетом и без +/- даты.

Можно "нормализовать" в самом PSQL запросе (filedDateTime)::timestamp или cast(filedDateTime as timestamp

Используется это

olegy123 писал(а):timestamp with time zone (время с часовым поясом).

Запрос в PGAdmin выглядит так
Кстати этот запрос сделан по данным из первой картинки первого сообщения
Вообще с PG время летит правильно - разработчик ZEOS сделал костыль

ssadragon писал(а):Где-то с месяц наверное в FPC что-то сломали по части временных зон.

А вот это не оно?

iskander писал(а):А вот это не оно?

Да скорре всего нет. У них линукс и проблема с функцией Now, я не вижу проблемы с этой функции у меня

Я о том что это проблема визуальных компонент по декодированию времени TRxMemoryData, думаю проще туда засылать уже нормализованное время (без +tz), туда попадает подрезанное. в системе Delphi время кодируется форматом double и у него нет смещения.
Сейчас (уже с времен XP) в системе есть декодирование времени - перевод из бинарного формата в текстовый "dd.mm.yyyy" c учетом и без региональных настроек.
Ну еще можно скорректировать непосредственно в самом запросе SET TIME ZONE Postgresql будет выравнивать у себе часовой пояс и выдавать без (+/- tz).

В транковом FPC целых 2 проблемы с датой/временем
1. таймзона. в линухе не верно читался файл данными таймзон. Now всегда возвращал время по гринвичу - без смещения.
https://bugs.freepascal.org/view.php?id=38630
вроде поправили - по крайней мере сейчас у меня работает нормально.
2. Есть ошибка с работой функции trunc с типом данных comp. Округляет математически (то что меньше ,5 до 0 а больше - до 1). Хотя всегда должна до нуля - так и в документации описано.
А проявляется это внутри функции MSecsToTimeStamp - там именно она использована. И дата/время после 12 часов дня улетает в следующий день.
https://bugs.freepascal.org/view.php?id=38631
Баг открыт - народ пока не осознал проблемы.
Для себя я поправил в исходниках RTL функции как во вложении к багрепорту.

Пишите в багтрекер FPC - может быстрее прочухаются?

Доброго времени!
Алекс 2-ая проблема как раз про меня. Большое спасибо! То что нужно было. Я вашего коммента больше всего и ждал, т.к. почему-то думал что он и решит мою проблему А Florian редиска блин.

ревизия FPC 49247 - исправили ошибку MSecsToTimeStamp - теперь дата/время из БД будет верно отображаться после полудня.