А, собственно, почему недостаток? Значение ведь получается не от того поля которое в базе, и тогда какого, собственно, подсовывать описание не от него?

Исходное поле должно иметь описание типа "Дата-время события в UTC".
А новое поле - это "Дата-время события в localtime".

В свое время думал о подобной конструкции - запихать в базу подписи к полям, но отказался, в т.ч. и по твоей причине. У меня в запросах много полей - производных от чего-то. Кроме того, пихать длинные подписи в Caption колонки в гриде неэффективно - их не видно. А вот если поле редактировать - то там можно/нужно и длинное описание показать. Это приводит к тому что единственного описания будет недостаточно.

Активно использую комментирование полей и таблиц в базе, но чисто в целях разработки, для себя же.

Тогда почему я вижу этот топик?

Собственноручно пихать в реляционную базу строку CSV, с тем что бы потом обратно ее разбирать??
А не проще ли было бы, вместо rdb$fields.rdb$description, сделать свою таблицу, сразу с нужными колонками?

Я бы взял вариант 2 и подумал над механизмом подписи полей не из rdb$fields.rdb$description.

Не знаю, переваривают ли такое датасеты, а просто TpFIBQuery нормально отдает такие конструкции



Или например, продумать систему именования полей, что бы они не пересекались ни с чем, и описания к ним засунуть в отдельную таблицу, наподобие rdb$fields.rdb$description.
В конструкции подтягивания заголовков сделать обход сначала rdb$fields.rdb$description, а если остались пустые заголовки - то идем в отдельную таблицу с заголовками.

Подсовывать чего-либо в TField.OnGetText считаю в корне неправильным.

Запрос возвращает одно значение, а видим мы другое? Это нормально?
А давайте поставим условие по дате. Ой... а чего-то оно неправильно срабатывает...


С не меньшим успехом можно подсовывать и в запросе. Правда поле будет уже не TDateTime а String.

В FB2.5 булевых полей нет.
Вместо них использую smallint, иногда char.

Нет. Не дорисовываю.
Булево поле, если оно мне нужно на клиенте так как оно нужно в базе - я тащу на клиента как есть.
Если мне нужно его как-то "не так" отобразить - то в запросе его же привожу к нужному виду, через iif или case, и тащу вторым полем, чисто "для посмотреть".
Исходное поле при этом может быть и скрытым. Оно будет доступно для всяких обработок на клиенте, а смотреть клиент будет на его визуальную копию. Но открыв скрытое поле с "исходником" можно получить доступ к тому что на самом деле в поле лежит.

Т.к. я не храню заголовки полей в базе а прописываю их на клиенте по месту выполнения запроса, то проблемы как у автора топика у меня нет.

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


Работает корректно, только видим мы несколько не то что хотим.

> Исходная задача: в таблице есть поле DATE_CREATED, в котором хранится время в UTC.
> Необходимо отобразить в DBGrid локальное время для текущего клиента.

Я бы еще обратил внимание на то, что сама задача - далеко не так однозначна как кажется на первый взгляд.

К примеру, я живу в городе, в котором за время моей жизни смещение от UTC менялось 3 раза.
Соответственно, смещение от UTC - это может быть далеко не константа.

Ты видимо не понял "глубину глубин".
Тут ни константой ни переменной не обойтись.

Дело не в том что в твоей географии присутствуют клиенты из разных часовых поясов, а в том что для конкретного географического пункта смещение от UTC в разные периоды времени может быть разным. Так же могут меняться границы часовых поясов. Сегодня город/область в одном поясе, а завтра - в другом.

Википедия: tz database
Хабр: Tzdata — глобальная база знаний о часовых поясах

На практике, это так же не панацея.

Лично столкнулся с тем что:
- пакет в линуксе, который работает с Tzdata, перестал обновляться, т.к. изменился формат самой Tzdata.
- обновить пакет что бы он работал с новым форматом не получилось - слишком старый был линукс
- после того как удалось победить 2 первых пункта, оказалось, что информация по моему городу в нем неактуальна
И оставалась неактуальна длительное время, и кажись так актуальной и не стала (стала, но к тому времени я уже перестал на это надеяться).
А город не какой-то мелкий, а третий в России по населению .

Т.к. в России отменили переход на летнее/зимнее время, это позволило выбрать тупо фиксированное смещение. Но это, естественно, не позволяет таким образом корректно вычислить смещение задним числом (т.к. информация в базе неверна), и никто не гарантирует что опять кто-то не выдумает игры с часовым поясом.

Поэтому, если информация о корректности в локальном времяисчислении критична, я бы подумал над собственной версией Tzdata для своей географии. Что бы в случае чего - не ждать манны от бесплатных общественных сервисов.

Вот такая красота для НСО. Да и не только.

Ух-ты, даже не 3 раза менялось, а 7 раз!