Показать сообщение отдельно
Старый 03.09.2011, 22:58   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Wamr Посмотреть сообщение
Я не думаю, что нужно будет что-то менять в ядре. На мой взгляд должна быть инструкция о том, как правильно перевести систему в условия новых часовых поясов.
Вообще, когда вызывается, скажем, метод DateTimeUtil::applyTimeZoneOffset(), то клиент (если дело происходит на клиенте) получает информацию о временной зоне, преобразует исходную UtcDateTime в структуру SYSTEMTIME и вызывает SystemTimeToTzSpecificLocalTime для получения локального времени в указанной временной зоне, после чего преобразует результат обратно в "свой" формат даты/времени. Информация о временной зоне при этом передается примерно в таком виде (для Москвы):
Код:
Bias = -180;
StandardName[32] = "";
StandardDate = 0000.10.05 03:00:00.000;
StandardBias = 0;
DaylightName[32] = "";
DaylightDate = 0000.03.05 02:00:00.000;
DaylightBias = -60;
Т.е. годы и названия временных зон не указываются.
Информация о временных зонах кэшируется внутри клиента - он держит в памяти массив э... вроде как упорядоченных по году связанных списков из классов CTimeZoneInfo (во всяком случае, так они называются в отладочной информации), где указана приведенная выше информация. Самое интересное, что данные для CTimeZoneInfo клиент получает от сервера, стек вызовов при этом выглядит примерно так:
Код:
  Memory  ChildEBP RetAddr  
          0028da78 006abadd Ax32!CTimeZoneInfo::UnPackTimeZoneRules
      2f8 0028dd70 006abf60 Ax32!Srv_DBSessionGet+0x601
       bc 0028de2c 006ac501 Ax32!CSessionMgr::CreateNewClientSession+0xa4
      144 0028df70 005c99a8 Ax32!CSessionMgr::CreateMainSession+0x1b3
     19c8 0028f938 009705d5 Ax32!gopts+0x1fd4
      238 0028fb70 005a6a48 Ax32!xApp::init+0x20a
И хотя клиентский код, возвращающий информацию о временной зоне, который вызывается внутри DateTimeUtil::applyTimeZoneOffset(), получает в качестве параметра год, для которого нужна информация, похоже, данные хранятся лишь в разрезе временных зон, но не в разрезе лет (т.е. связанные списки для каждой временной зоны состоят из одного элемента), оттого и нестыковки, вызванные отменой перехода на зимнее время с определенного года.
Т.е. похоже, что AOS где-то у себя "оптимизирует" хранение данных о временных зонах исходя из предположения, что правила перехода на летнее/зимнее время не меняются с годами, и передает эту "оптимизированную" информацию клиентам, подключающимся к нему, - оттого и нули в годах в структуре TIME_ZONE_INFORMATION, передаваемой функции SystemTimeToTzSpecificLocalTime(), оттого и нестыковки с новыми правилами (не)перехода на зимнее время. Так что, мне кажется, патч для ядра все же понадобится...

PS. Проверялось все на ядре RU7.
За это сообщение автора поблагодарили: Wamr (3).