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

[Wamr]

Наверное, все слышали, что переход на зимнее время отменен.
В связи с этим, вышло обновление для Windows, после которого все российские часовые пояса сдвинулись на +1. Например, Москва теперь GMT+4.

Сейчас аксаптовский клиент стал ругаться о смене часового пояса.
А как отразится на работе системы необновление часового пояса на АОСе или сервере БД? Как поведет себя система в день Х, когда часть компьютеров попытаются по старинке сменить себе время?

[sukhanchik]

Если есть расхождение по времени с контроллером домена - то вроде бы комп лишится сети и будет сильно ругаться на несоответствие времени.
Хотя точно не знаю - ибо встречал как наличие ругани, так и ее отсутствие (видимо дело в настройках)

[AndyD]

У меня складывается впечатление, что DAX2009 использует какие-то свои, внутренние, средства для работы с UTCDateTime, а не системные

Небольшой эксперименты на связке WIN2008R2 с установленным обновлением KB2570791 (а так же на WinXP) и DAX2009 SP1 RU7 показали, что в ноябре 2011 Аксапта записывает время со сдвигом на +3:00UTC для стандартного Российского времени, т.е. она считает, что осенью стрелки будут переводиться, хотя в системе переход уже отменен


Так что, похоже, надо ждать обновление ядра или придется менять часовую зону у пользователей в час Х

[Wamr]

Андрей, ты же сам сказал системе "сделай UTC из системного с учетом настройки часового пояса пользователя (в DAX)", вот и вышло +3. А как createdDateTime и тп сформируется?

В соседней ветке еще есть упоминание настроек пояса в компании

[AndyD]

Цитата:

Сообщение от Wamr

Андрей, ты же сам сказал системе "сделай UTC из системного с учетом настройки часового пояса пользователя (в DAX)", вот и вышло +3.

Да, совершенно верно.
Но вот только я как раз и проверял, откуда Аксапта берет параметры этого часового пояса. И если бы она брала из системы - то и смещение было бы +4.
Что можно увидеть на примере дотнетового кода, к примеру

В первой строке - время UTC, во-второй - мое локальное, в третьей - мои настройки тайм-зоны

Цитата:

Сообщение от Wamr

А как createdDateTime и тп сформируется?

DateTimeUtil::utcNow() возвращает правильное время. В createdDateTime и modifiedDateTime время тоже правильное (в базе данных).
Вот только отображается оно в интерфейсе неправильно И фильтруется тоже неправильно.

[gl00mie]

Цитата:

Сообщение от sukhanchik

Если есть расхождение по времени с контроллером домена - то вроде бы комп лишится сети и будет сильно ругаться на несоответствие времени. Хотя точно не знаю - ибо встречал как наличие ругани, так и ее отсутствие (видимо дело в настройках)

Будет-будет ругаться и сети лишится точно. Насколько я помню, с контроллером домена (точнее, эмулятором PDC) время может расходиться максимум на 15 минут, если больше - досвидос, подкручивайте часы.

Цитата:

Сообщение от Wamr

А как createdDateTime и тп сформируется?

Не знаю, как с базами на Ms SQL Server, а с оракловыми эти вещи и все, где фигурирует DateTimeUtil::utcNow(), синхронизируется с СУБД, причем на каждый чих, т.е. systemdateget() может отработать и локально, а вот DateTimeUtil::utcNow() приведет к отправке запроса на СУБД, и вот как та перейдет (или не перейдет) на зимнее время - так фишка и ляжет.

[AndyD]

На MS SQL при вызове DateTimeUtil::utcNow() и при сохранении/модификации записей с включенными created* и modified*, тоже запрос на сервер отправляется

select  DATEPART(d,  GETUTCDATE()),         DATEPART(m,  GETUTCDATE()),         DATEPART(yy, GETUTCDATE()),         DATEPART(hh, GETUTCDATE()),         DATEPART(n,  GETUTCDATE()),         DATEPART(s,  GETUTCDATE())

[kashperuk]

Правильно ли я понимаю, что без заплатки для кернела проблема не решится?

[AndyD]

По-моему, да

[kashperuk]

ОК. Кто-то создал support request?
Насколько серьезна эта проблема для ваших инсталляций?
Я могу поговорить с ребятами из kernel команд, но было бы здорово иметь ответы на вопросы выше перед этим.

[Wamr]

Я не думаю, что нужно будет что-то менять в ядре.
На мой взгляд должна быть инструкция о том, как правильно перевести систему в условия новых часовых поясов.
Хочется, чтобы специалисты MS озадачились этим вопросом, попробовали перевести тестовую систему и рассказали нам какие нас ждут трудности и неприятности, если сделать не так.

[Jabberwocky]

Похоже, что все-таки без фикса kernel не обойтись - Аксапта использует внутренний параметр в настройках пользователя для отображения дат, где все осталось по-старому:

[Wamr]

не считаю что preferred time zone должно совпадать с настройками локального времени. Это же enterprise система.
Только текст неправильный. А настройки пользователя и компании легко правятся запросиком.

[AndyD]

Ну, текст - это не самая большая проблема. В конце концов, его можно и ручками поправить (в *.ktd)

Проблема в том, что если у пользователя менять preferred time zone на подходящую (к примеру, для RST - на GMTPLUS0400ABUDHABI_MUSCAT), то либо на этой тайм-зоне вообще нет DST и тогда исторические данные за предыдущие периоды будут неправильными, либо DST есть, но не совпадает с Российским (да и замена в таком случае - шило на мыло)

Если же зону не менять вообще, то будем иметь вот такую картину, неприемлемую с моей точки зрения

Да и еще, есть куча мест в коде, где используется DateTimeUtil::newDateTime() совместно с DateTimeUtil::getUserPreferredTimeZone()

[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.

[kashperuk]

Выслал письмо в команду разработки ядра, будем ждать, что ответят.

[Wamr]

а как вам нравятся таблички
TimeZonesList
TimeZonesRulesData
вроде они должны помочь

[AndyD]

Цитата:

Сообщение от gl00mie

Т.е. похоже, что AOS где-то у себя "оптимизирует" хранение данных о временных зонах исходя из предположения, что правила перехода на летнее/зимнее время не меняются с годами, и передает эту "оптимизированную" информацию клиентам, подключающимся к нему, - оттого и нули в годах в структуре TIME_ZONE_INFORMATION, передаваемой функции SystemTimeToTzSpecificLocalTime(), оттого и нестыковки с новыми правилами (не)перехода на зимнее время. Так что, мне кажется, патч для ядра все же понадобится...

Это не так.
Что бы убедиться - достаточно посмотреть параметры смены DST зоны GMTMINUS0800PACIFICTIME для 2006 и 2007 годов (нули в годах означают, что дата смены будет формироваться динамически).

Насчет патча - посмотрим, что Ивану отпушут

[gl00mie]

Конгениально! Похоже, все и правда можно решить настройками. У меня вроде как все рассосалось после подкручивания данных в TimeZonesRulesData вот таким джобом (запускать его надо на сервере!):

#macrolib.TimeConstants
#define.NewRuleId1  (61002)
#define.NewRuleId2  (61003)
TimeZonesRulesData  tzRuleData;
;
if (!isRunningOnserver())
{
    throw error( @"Код должен выполняться на сервере" );
}
new SkipAOSValidationPermission().assert();
ttsbegin;
tzRuleData.skipAosValidation( true );
select firstonly forupdate tzRuleData
    where   tzRuleData.RuleId == #NewRuleId1
            ;
if (!tzRuleData)
{
    tzRuleData.clear();
    tzRuleData.initValue();
}
tzRuleData.RuleId   = #NewRuleId1;
tzRuleData.TzEnum   = Timezone::GMTPLUS0300MOSCOW_STPETERSBURG_VOLGOGRAD;
tzRuleData.Bias     = -180;
tzRuleData.Year     = 2011;
tzRuleData.SYear    = tzRuleData.Year;
tzRuleData.SMonth   = MonthsOfYear::December;
tzRuleData.SDay     = dayOfMth( endMth( mkDate( 1, tzRuleData.SMonth, tzRuleData.SYear ) ) );
tzRuleData.SHour    = #hoursPerDay - 1;
tzRuleData.SMinute  = #MinutesPerHour - 1;
tzRuleData.SSecond  = #secondsPerMinute - 1;
tzRuleData.DYear    = tzRuleData.Year;
tzRuleData.DMonth   = MonthsOfYear::March;
tzRuleData.DDay     = 27;
tzRuleData.DHour    = 2;
tzRuleData.DBias    = -60;
// NB! не вызываем validateWrite(), потому что ВСЕ поля в таблице обязательны к заполнению
tzRuleData.write();

select firstonly forupdate tzRuleData
    where   tzRuleData.RuleId == #NewRuleId2
            ;
if (!tzRuleData)
{
    tzRuleData.clear();
    tzRuleData.initValue();
}
tzRuleData.RuleId   = #NewRuleId2;
tzRuleData.TzEnum   = Timezone::GMTPLUS0300MOSCOW_STPETERSBURG_VOLGOGRAD;
tzRuleData.Bias     = -240;
tzRuleData.Year     = 2012;
// NB! не вызываем validateWrite(), потому что ВСЕ поля в таблице обязательны к заполнению
tzRuleData.write();
ttscommit;
info( strfmt( @"Данные в %1 обновлены", tablestr(TimeZonesRulesData) ) );

[AndyD]

Аксапта круче чем Винда

Потому как в патче, фактически, просто отрубили DST для 2011 года.