AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 31.08.2011, 10:29   #1  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Y2K11 или переход на зимнее время
Наверное, все слышали, что переход на зимнее время отменен.
В связи с этим, вышло обновление для Windows, после которого все российские часовые пояса сдвинулись на +1. Например, Москва теперь GMT+4.

Сейчас аксаптовский клиент стал ругаться о смене часового пояса.
А как отразится на работе системы необновление часового пояса на АОСе или сервере БД? Как поведет себя система в день Х, когда часть компьютеров попытаются по старинке сменить себе время?
Старый 31.08.2011, 10:55   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Если есть расхождение по времени с контроллером домена - то вроде бы комп лишится сети и будет сильно ругаться на несоответствие времени.
Хотя точно не знаю - ибо встречал как наличие ругани, так и ее отсутствие (видимо дело в настройках)
__________________
Возможно сделать все. Вопрос времени
Старый 31.08.2011, 19:13   #3  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
У меня складывается впечатление, что DAX2009 использует какие-то свои, внутренние, средства для работы с UTCDateTime, а не системные

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


Так что, похоже, надо ждать обновление ядра или придется менять часовую зону у пользователей в час Х
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: Atar (1), S.Kuskov (3).
Старый 31.08.2011, 23:52   #4  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Андрей, ты же сам сказал системе "сделай UTC из системного с учетом настройки часового пояса пользователя (в DAX)", вот и вышло +3. А как createdDateTime и тп сформируется?

В соседней ветке еще есть упоминание настроек пояса в компании
За это сообщение автора поблагодарили: S.Kuskov (3).
Старый 01.09.2011, 10:05   #5  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Цитата:
Сообщение от Wamr Посмотреть сообщение
Андрей, ты же сам сказал системе "сделай UTC из системного с учетом настройки часового пояса пользователя (в DAX)", вот и вышло +3.
Да, совершенно верно.
Но вот только я как раз и проверял, откуда Аксапта берет параметры этого часового пояса. И если бы она брала из системы - то и смещение было бы +4.
Что можно увидеть на примере дотнетового кода, к примеру

В первой строке - время UTC, во-второй - мое локальное, в третьей - мои настройки тайм-зоны
Цитата:
Сообщение от Wamr Посмотреть сообщение
А как createdDateTime и тп сформируется?
DateTimeUtil::utcNow() возвращает правильное время. В createdDateTime и modifiedDateTime время тоже правильное (в базе данных).
Вот только отображается оно в интерфейсе неправильно И фильтруется тоже неправильно.
__________________
Axapta v.3.0 sp5 kr2
Старый 02.09.2011, 02:47   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Если есть расхождение по времени с контроллером домена - то вроде бы комп лишится сети и будет сильно ругаться на несоответствие времени. Хотя точно не знаю - ибо встречал как наличие ругани, так и ее отсутствие (видимо дело в настройках)
Будет-будет ругаться и сети лишится точно. Насколько я помню, с контроллером домена (точнее, эмулятором PDC) время может расходиться максимум на 15 минут, если больше - досвидос, подкручивайте часы.
Цитата:
Сообщение от Wamr Посмотреть сообщение
А как createdDateTime и тп сформируется?
Не знаю, как с базами на Ms SQL Server, а с оракловыми эти вещи и все, где фигурирует DateTimeUtil::utcNow(), синхронизируется с СУБД, причем на каждый чих, т.е. systemdateget() может отработать и локально, а вот DateTimeUtil::utcNow() приведет к отправке запроса на СУБД, и вот как та перейдет (или не перейдет) на зимнее время - так фишка и ляжет.

Последний раз редактировалось gl00mie; 02.09.2011 в 02:50.
Старый 02.09.2011, 07:17   #7  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
На MS SQL при вызове DateTimeUtil::utcNow() и при сохранении/модификации записей с включенными created* и modified*, тоже запрос на сервер отправляется
X++:
select  DATEPART(d,  GETUTCDATE()),         DATEPART(m,  GETUTCDATE()),         DATEPART(yy, GETUTCDATE()),         DATEPART(hh, GETUTCDATE()),         DATEPART(n,  GETUTCDATE()),         DATEPART(s,  GETUTCDATE())
__________________
Axapta v.3.0 sp5 kr2
Старый 02.09.2011, 10:26   #8  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Правильно ли я понимаю, что без заплатки для кернела проблема не решится?
Старый 02.09.2011, 14:35   #9  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
По-моему, да
__________________
Axapta v.3.0 sp5 kr2
Старый 02.09.2011, 14:48   #10  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
ОК. Кто-то создал support request?
Насколько серьезна эта проблема для ваших инсталляций?
Я могу поговорить с ребятами из kernel команд, но было бы здорово иметь ответы на вопросы выше перед этим.
Старый 02.09.2011, 17:53   #11  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Я не думаю, что нужно будет что-то менять в ядре.
На мой взгляд должна быть инструкция о том, как правильно перевести систему в условия новых часовых поясов.
Хочется, чтобы специалисты MS озадачились этим вопросом, попробовали перевести тестовую систему и рассказали нам какие нас ждут трудности и неприятности, если сделать не так.
Старый 02.09.2011, 22:35   #12  
Jabberwocky is offline
Jabberwocky
Microsoft Dynamics
Аватар для Jabberwocky
Сотрудники Microsoft Dynamics
 
274 / 307 (11) ++++++
Регистрация: 02.09.2005
Адрес: Москва
Похоже, что все-таки без фикса kernel не обойтись - Аксапта использует внутренний параметр в настройках пользователя для отображения дат, где все осталось по-старому:
Изображения
  
__________________
You should use Bing before asking dumb questions.

Последний раз редактировалось Jabberwocky; 02.09.2011 в 22:46.
Старый 03.09.2011, 00:43   #13  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
не считаю что preferred time zone должно совпадать с настройками локального времени. Это же enterprise система.
Только текст неправильный. А настройки пользователя и компании легко правятся запросиком.
Старый 03.09.2011, 07:49   #14  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Ну, текст - это не самая большая проблема. В конце концов, его можно и ручками поправить (в *.ktd)

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

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

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

Последний раз редактировалось AndyD; 03.09.2011 в 07:54.
Старый 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).
Старый 04.09.2011, 00:27   #16  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Выслал письмо в команду разработки ядра, будем ждать, что ответят.
Старый 04.09.2011, 12:00   #17  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
а как вам нравятся таблички
TimeZonesList
TimeZonesRulesData
вроде они должны помочь
За это сообщение автора поблагодарили: Logger (3), AndyD (10), gl00mie (10).
Старый 04.09.2011, 16:25   #18  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Т.е. похоже, что AOS где-то у себя "оптимизирует" хранение данных о временных зонах исходя из предположения, что правила перехода на летнее/зимнее время не меняются с годами, и передает эту "оптимизированную" информацию клиентам, подключающимся к нему, - оттого и нули в годах в структуре TIME_ZONE_INFORMATION, передаваемой функции SystemTimeToTzSpecificLocalTime(), оттого и нестыковки с новыми правилами (не)перехода на зимнее время. Так что, мне кажется, патч для ядра все же понадобится...
Это не так.
Что бы убедиться - достаточно посмотреть параметры смены DST зоны GMTMINUS0800PACIFICTIME для 2006 и 2007 годов (нули в годах означают, что дата смены будет формироваться динамически).

Насчет патча - посмотрим, что Ивану отпушут
__________________
Axapta v.3.0 sp5 kr2
Старый 04.09.2011, 16:28   #19  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Конгениально! Похоже, все и правда можно решить настройками. У меня вроде как все рассосалось после подкручивания данных в TimeZonesRulesData вот таким джобом (запускать его надо на сервере!):
X++:
#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) ) );
Старый 04.09.2011, 20:01   #20  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Аксапта круче чем Винда

Потому как в патче, фактически, просто отрубили DST для 2011 года.
__________________
Axapta v.3.0 sp5 kr2
Теги
time, time zone, utc, utcdatetime, зимнее время, часовые пояса

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Время транспортировки в часах Innokentiy DAX: Программирование 2 21.07.2011 15:44
DAX2009 зафиксировать дату и время сеанса Raven Melancholic DAX: Функционал 3 25.04.2011 16:26
Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления gl00mie DAX: Администрирование 5 02.01.2011 23:37
Время по графику и фактическое время работы в табеле nicko DAX: Функционал 0 09.02.2005 15:24
Установить время файла? SnowMan DAX: Программирование 5 01.10.2003 14:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:08.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.