Y2K11 или переход на зимнее время

[gl00mie]

Цитата:

Сообщение от 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.