hvladrdb_devЕсли бы TIMESTAMP хранился на сервере в UTCОн там хранится в UTCЯ имею в виду 64-битный штамп времени - 'TIMESTAMP WITHOUT TIME ZONE'

hvladrdb_devи также передавался до клиентской библиотекеНакуа клиенту UTC ?А почему БЫ нет, если fbclient экспортирует две функции - с UTC и локальным временем?

hvladrdb_devтак как все нормальные операционные системы имеют у себя актуальную информацию о часовых поясах (если регулярно обновляются)Вот это вот ЕСЛИ тебя губит.Лишь меня? Часто ли администраторы серверов ФБ обновляют их из снапшотов, даже при незначительных патчах? Теперь представь, что в государстве поменялся UTC DST или какой-то населённый пункт стал частью другого административно-территориального деления с другим часовым поясом, вы внесли соответствующие изменения, выкатели снапшот и что дальше? Администраторы серверов ФБ все как один ошалело ринулись обновлять свои серваки? Чот сомневаюсь я...

hvladИ не надо мне рассказывать про WinApi, я немножко его знаю.
В отличие от тебя, показывающего не те ф-ции и не понимающего что в них не так.Ну и ладно!... Добавить суффикс Ex и перед вызовом получать DYNAMIC_TIME_ZONE_INFORMATION вместо TIME_ZONE_INFORMATION.

hvladИ если потрудишься таки почитать доку, то узнаешь, что строковые идентификатры регионов в Win ни разу не соответствуют оным в ICU (IANA)Это не самая большая проблема, тем более, что в большинстве случаев это нафиг не надо, так как локальное время в fbclient через функции ОС и так сконвертируется без всяких идентификаторов часовых поясов.

Гаджимурадов РустамА откуда сервер узнает часовой пояс клиента?Вопрос с отрывом от контекста. Очень сложно понять - ты спрашиваешь или пытаешься кому-то возразить, задавая наводящие вопросы.
Вообще, SET TIME ZONE <tz_identifier>

hvladrdb_dev, я вообще перестал понимать твой словесный потокТы просто устал. Хороших выходных! :)

Форумяне, объясните мне, плз, результат. Сервер FirebirdSQL v4.0 (WI-T6.3.0.1510 Firebird 4.0 Beta 1) и isql (от него же) запущены на одном и том же компе под Win7. Время в системе московское и на момент выполнения запроса соответствует второму результату - '2019-06-21 10:44:46.8510 Europe/Moscow'. при выполнении в isql:

Получаю результат:
Т.е., CURRENT_TIMESTAMP выдаёт корректный результат, а приведение литерала 'NOW' выдаёт текущее время системы как UTC. Отсюда возникает пара вопросов:
1. Литерал 'NOW' интерпретируется именно как время клиента по UTC+Offset, где Offset определяется путём согласования времени между сервером и клиентом в подключении?
2. Корректность CURRENT_TIMESTAMP означает, что сервер в контексте SYSTEM имеет свой идентификатор часового пояса, определяемый через средства ОС?

Чот не догоняю логику сервера... :(

Симонов Денис, нет, используется по умолчанию.

# Default session or client time zone.
#
# If empty, the default is the OS time zone.
# When set in the server, it defines the default session time zone for attachments.
# When set in the client, it defines the default time zone used with client-side API functions.
#
# Type: string
#
#DefaultTimeZone =

Симонов Дениснет. Ещё раз прочитай описания параметра DefaultTimeZone.Почитал, проверил и в очередной раз убедился, что к часовому поясу сервера этот параметр конфигурации вообще никак не относится. Собственно, там и написано, что параметр конфигурации сервера DefaultTimeZone отвечает за выбор часового пояса по умолчанию для клиентской сессии. Иными словами, для всех подключающихся клиентов сервер будет по умолчанию задавать указанный в параметре DefaultTimeZone часовой пояс, который клиент может переопределить тем же SET TIME ZONE.

Для проверки в конфигурационном файле сервера изменил DefaultTimeZone=UTC, перезапустил службу сервера, скопировал isql, fbclient.dll и icu файлы в отдельный каталог, откуда и запустил isql, выдав вышеприведённые "ыудусе" без предварительного SET TIME ZONE 'UTC'. Результат тот же и в точности с описанием параметра в конфигурационном файле:


Потому в контекстах SYSTEM и USER_SESSION необходимо иметь разные контекстные переменные TIME_ZONE, из которых можно было бы получить часовой пояс сервера и часовой пояс клиента. Проблема только в сопоставлении часовых поясов IANA с представлением на ОС Windows.

hvladСимонов ДенисПро 'NOW' напиши в трекер, чёт мне кажется это поведение не верное+1Данную проблему в трекере нужно описывать тому, кто способен её изложить на вразумительном инглише. Это не про меня... На форуме даже не всегда понимают то, что я излагаю на русском. :)

kdv, не помню. Надо будет в понедельник проверить.

hvladkdvу тебя фб 4 не зарегано в реестре через instreg?Поиск конфига\клиента\и т.п. в реестре выпилили ещё в fb3ФБ3 не ставил. Выпилил всю ветку реестра [HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project], в ветке [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node] такого раздела не обнаружил, в конфиге сервера выставил DefaultTimeZone=UTC, перезапустил службу сервера. Из каталога сервера скопировал в отдельный каталог файлы: fbclient.dll, firebird.conf, firebird.msg, icudt63.dll, icudt63l.dat, icuin63.dll, icuuc63.dll, isql.exe. В конфиге клиента DefaultTimeZone по умолчанию.

Снова выполняю запрос без предварительного SET TIME ZONE, результат неизменен:

Далее выставил в конфиге клиента "DefaultTimeZone=Europe/Moscow", перезапустил клиент сделал запрос - результат не изменился. Затем сделал SET TIME ZONE 'Europe/Moscow', результат:

ЧЯДНТ?

Хочу обратить внимание, что параметр конфигурации DefaultTimeZone клиента не перекрыл соответствующий параметр конфигурации сервера, что, на мой взгляд, некомильфо.

Симонов Денисrdb_dev,

ну так ты будешь Адриано писать? Или за тебя это сделать?

Правда я думаю это не в трекер пока надо, а для начала в fb-devel чтобы разъяснили, а то может сам дурак.Неа, не буду!
Dimitr на одном из семинаров как-то говорил, что если не можете внятно на инглише изложить проблему в трекере, пишите на русском здесь - на форуме sql.ru, а мы, дескать, сами создадим тикет в трекере. :) Так что, пользуясь случаем...