| Начало » Использование СУБД » 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 с помощью запроса
 
 С помощью отладчика, меняем внутрях у отладочного сервера название timezone "Europe/Moscow" (id: 65064) на "Kurope/Moscow".select extract(TIMEZONE_HOUR  from cast('2023-06-19 10:02:30 Europe/Moscow' as timestamp with time zone)) from rdb$database;
 
  
 И видим, что 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 Сообщений: 152
 Зарегистрирован: 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 Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Я когда смотрел инфу по своей таймзоне в базе, то на моей памяти вроде бы было 2 изменения. А оказалось что порядка 6-8 изменений, точно не помню, но гораздо больше чем я ожидал. Там не только смещение от GMT, но и различные флюктуации с летним/зимним временем - то оно есть, то нету, то нету но все время по зимнему, но нету но все время по летнему, и т.п. 
 И кстати, все эти штуки приводят к тому что временные диапазоны по локальному времени считать будет не совсем корректным.
 
 [Обновления: Mon, 03 July 2023 03:48] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  | 
 
 
 Текущее время: Fri Oct 31 20:34:51 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.00930 секунд |