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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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