Начало » Использование СУБД » Firebird, HQbird, InterBase » Неизвестная time zone и ucal_open [ICU] (пятничный треш / развлечение)
Неизвестная time zone и ucal_open [ICU] [сообщение #2670] |
Fri, 30 June 2023 09:36 |
Dmitry Kovalenko
Сообщений: 51 Зарегистрирован: December 2022
|
Member |
|
|
С пятницей.
Опишу эксперимент - может чего сам пойму
Как широко известно в узких кругах, для обработки часовых зон FB использует ICU.
Если вы передадите серверу неизвестное ИМЯ часовой зоны - "Kurope/Moscow", сервер вернет ошибку "Invalid time zone region: Kurope/Moscow":
Возник вопрос - а что будет, если в само ICU засунуть неизвестное имя часовой зоны?
Если более конкретно - как поведет себя ICU-шная функция ucal_open с неизвестным именем timezone?
В случае сервера, мы можем вызвать ucal_open с помощью запроса
select extract(TIMEZONE_HOUR from cast('2023-06-19 10:02:30 Europe/Moscow' as timestamp with time zone)) from rdb$database;
С помощью отладчика, меняем внутрях у отладочного сервера название timezone "Europe/Moscow" (id: 65064) на "Kurope/Moscow".
И видим, что ICU без ошибок переваривает это имя. Extract TIMEZONE_HOUR возвращает 0:
Чтобы убедиться, что сервер реально сломан, выполним простой запрос с преобразованием туда и обратно:
select cast(cast('2023-06-19 10:02:30 Europe/Moscow' as timestamp with time zone) as VARCHAR(128)) from rdb$database;
Видим, что таки да - сервер мы поломали правильно:
---
Пока ваял этот спич, подумал - может надо было сломать пожостче. Скажем, поменять имя нашей часовой зоны 65064 на "Kurope/Loscow"?
ucal_open и такое переваривает без ошибок.
Обратная проверка:
---
Вывод - походу если ICU перестанет поддерживать какой-нибудь часовой пояс, то сервер это дело не прорюхает. И, возможно, будут проблемы.
Короче, (риторические) вопросы - кто виноват и чего делать-то?
---
Всем бобра и хорошего настроения.
|
|
|
Re: Неизвестная time zone и ucal_open [ICU] [сообщение #2673 является ответом на сообщение #2670] |
Fri, 30 June 2023 11:36 |
fraks
Сообщений: 140 Зарегистрирован: June 2022 Географическое положение: Новосибирск
|
Senior Member |
|
|
С временнЫми зонами все гораздо сложнее.
Мало того что они должны быть с нужным именем, так еще и информация об этой зоне должна быть актуальна не только на текущий момент, но и на прошлые и на будущие.
Если с прошлым более-менее ясно, то с текущим и будущим - сложнее. Данные про зону - не константа и меняются со временем. Причем от фактически законодательного решения о смене информации о зоне, до попадания этой инфы в базу tzdata, и попадание оттуда в локально установленную ICU-библиотеку, или в локальную БД по tzdata - пройдет некоторое время. В моем случае, информация по изменениям в мой зоне не попадали в первоисточник несколько месяцев, и даже когда попали, то оказалось что на текущем сервере стоит старый пакет tzdata который не умеет брать данные в новом формате, а старого формата или уже нет или он не обновляется.
https://habr.com/ru/articles/130401/
По этой причине я бы крайне осторожно относился к внедрению такого формата даты-времени в базу. Ибо это лишние зависимости от окружающей системы и мира. Либо самостоятельно контролировать и поддерживать актуальность необходимых зон.
[Обновления: Mon, 03 July 2023 03:44] Известить модератора
|
|
|
Re: Неизвестная time zone и ucal_open [ICU] [сообщение #2674 является ответом на сообщение #2673] |
Fri, 30 June 2023 11:47 |
fraks
Сообщений: 140 Зарегистрирован: June 2022 Географическое положение: Новосибирск
|
Senior Member |
|
|
Я когда смотрел инфу по своей таймзоне в базе, то на моей памяти вроде бы было 2 изменения. А оказалось что порядка 6-8 изменений, точно не помню, но гораздо больше чем я ожидал. Там не только смещение от GMT, но и различные флюктуации с летним/зимним временем - то оно есть, то нету, то нету но все время по зимнему, но нету но все время по летнему, и т.п.
И кстати, все эти штуки приводят к тому что временные диапазоны по локальному времени считать будет не совсем корректным.
[Обновления: Mon, 03 July 2023 03:48] Известить модератора
|
|
|
|
|
|
|
|
|
|
Переход к форуму:
Текущее время: Sun Dec 22 20:52:29 GMT+3 2024
Общее время, затраченное на создание страницы: 0.00771 секунд
|