Начало » Использование СУБД » 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 перестанет поддерживать какой-нибудь часовой пояс, то сервер это дело не прорюхает. И, возможно, будут проблемы.
Короче, (риторические) вопросы - кто виноват и чего делать-то?
---
Всем бобра и хорошего настроения.
|
|
|
Переход к форуму:
Текущее время: Fri Nov 22 14:55:44 GMT+3 2024
Общее время, затраченное на создание страницы: 0.00825 секунд
|