03.09.2011, 22:58 | #11 |
Участник
|
Цитата:
Код: 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 Т.е. похоже, что AOS где-то у себя "оптимизирует" хранение данных о временных зонах исходя из предположения, что правила перехода на летнее/зимнее время не меняются с годами, и передает эту "оптимизированную" информацию клиентам, подключающимся к нему, - оттого и нули в годах в структуре TIME_ZONE_INFORMATION, передаваемой функции SystemTimeToTzSpecificLocalTime(), оттого и нестыковки с новыми правилами (не)перехода на зимнее время. Так что, мне кажется, патч для ядра все же понадобится... PS. Проверялось все на ядре RU7. |
|
|
За это сообщение автора поблагодарили: Wamr (3). |
Теги |
time, time zone, utc, utcdatetime, зимнее время, часовые пояса |
|
|