hvladВасилий 2,

Как мне поможет "текущий UTC" определить UTC для даты\времени события в Сингапуре через 4 года
(которое я хочу записать в БД - календарь) ?Очень просто! Прибавляешь к текущему UTC 4 года и получаешь UTC для даты/времени через 4 года где угодно и в Сигнапуре в том числе. UTC, он ведь и в Сигнапуре - UTC. Если тебе надо что-то пнуть на сервере в предполагаемое время, просто пинаешь, когда приходит срок, а если надо вернуть это время клиенту - возвращаешь его клиенту как есть и пусть клиент сам решает, что ему с этим UTC делать - приводить к локальному или хавать как есть.

Симонов Денисrdb_dev,
перестань маяться фигнёй. В текущей реализации дат с тайм-зонами время и так храниться в UTC + timezone idИ нафиг мне упёрлись эти два байта в каждой записи со временем, которые, при сильной необходимости, можно хранить в отдельном поле, взяв информацию из контекста сессии?

Симонов Дениспользователь вводит свою дату. Причём тут текущее время? Ты что там предлагаешь какие-то идиотские пересчёты через текущее время клиента делать?При установке Линуха пользователь тоже вводит свою дату, а установщик, по умолчанию, предполагает, что RTC хранит время в UTC. Как-то же справляется...

hvladЯ хочу записать в БД дату\время '12.5.2024 9:00' по Сингапурскому местному времени.
Как мне в этом поможет моё UTC ?Зачем в БД хранить именно Сингапурское время? В этом может быть какой-то особый смысл только в случае, когда необходимо знать из какого часового пояса был клиент, из сессии которого была инициирована в БД запись со штампом времени.

hvladrdb_devпусть клиент сам решает, что ему с этим UTC делать - приводить к локальному или хавать как естьЯ такой клиент, который не имеет у себя ICU и не может приводить UTC к локальному (да ещё и не местному).
Если бы у меня (клиента) был ICU - всего этого топика не было бы.Венда до WinX как-то справлялась с приведением времени и без icu библиотек - своими силами. Собственно, с этим прекрасно справляется любая нормальная операционная система.

Теперь представим ситуацию, что в БД ты записал UTC+сингапурский_id, рассчитанный на 4 года вперёд, а в этой республике за 4 года правительство выкатило постановление об изменении часового пояса и так как, ПРЕДПОЛОЖИМ, администратор сервера или разработчик БД или разработчики СУБД не следили за постановлениями правительства Сингапура и за изменениями IANA таблицы часовых поясов, данные об этих изменениях попали только в регулярно обновляющуюся у сингапурского клиента ОС. И чо?

hvladrdb_devИ нафиг мне упёрлись эти два байта в каждой записи со временем, которые, при сильной необходимости, можно хранить в отдельном поле, взяв информацию из контекста сессии?Тебя никто не заставляет пользоваться новыми типами данных.TIMESTAMP WITHOUT TIME ZONE хранит штамп времени в UTC?

Симонов Денисой как страшно целые 2 байта!!! А ничего, что DECFLOAT(34) требует аж 16 байт?+2 абсолютно бесполезных, в большинстве случаев, байта на каждую запись. Для хранения чисел с плавающей точкой есть широкий выбор типов данных и, ко всему прочему, в DECFLOAT все биты такого типа используются для необходимой разработчику БД точности числа, но с TIMESTAMP у меня нет такого широкого выбора - нет типа UTCSTAMP на 8 байт.

Симонов Денисrdb_devПри установке Линуха пользователь тоже вводит свою дату, а установщик, по умолчанию, предполагает, что RTC хранит время в UTC. Как-то же справляется...вы сударь фигню молвите. Пользователь может указать дату с другим (не своим) часовым поясом. И получать дату он может не обязательно в своём часовом поясеКонечно может! Пользователь выставляет часовой пояс, а ОС предполагает, что RTC хранит UTC и затем для графического отображения локального времени на экране система осуществляет приведение времени из UTC в локальное, в соответствии с выбранным пользователем часовым поясом. Это же очевидно!

Dimitry Sibiryakovrdb_devTIMESTAMP WITHOUT TIME ZONE хранит штамп времени в UTC?
Он хранит то, что ты в него положил.И как мне в триггере на добавление/обновление из CURRENT_TIMESTAMP или 'NOW' положить в поле TIMESTAMP WITHOUT TIME ZONE штамп времени в UTC, если в ОС сервера выбран часовой пояс 'Europe/Moscow', да так, чтобы и сервер FirebirdSQL и его клиент - fbclient понимали, что в этом поле имеют дело с UTC?

Симонов Денис, мне не нужен UTC с двумя байтами часового пояса. Мне нужен просто UTC - 8 байт.

Мимопроходящийкстати, в linux'е есть пакет tzdata.
который содержит данные о часовых поясах всего мира и правилах перехода на летнее/зимнее время.
он периодически обновляется, чтобы отразить изменения, принимаемые в различных странах.
и ICU ему для этого нафиг не нужен, вообще-то.
мухи отдельно, котлеты отдельно.

зы: только что прилетел пакет обновления.О том и речь! Но пацаны, почему-то, отказываются осознавать, что обновления часовых поясов в ОС прилетают чаще и автоматом, а для обновления информации о часовых поясах на сервере FirebirdSQL придётся делать дополнительные приседания. Вопрос - какие?

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

1. вообще-то в массе Windows распространён куда шире Linux
2. Идентификация часовых поясов в Win, Linux, Mac OS может быть сделана по разному. Влад уже говорил, что как минимум в Win и ICU они отличаются. Если делать таблицу соответствия, то поддерживать её это ничуть не лучше обновления ICUОднако, разработчики FirebirdSQL делают сборки для всех этих ОС и я сильно сомневаюсь, что сервер использует исключительно POSIX API и нигде не использует #ifdef с индивидуализацией кода по ОС.