MS CRM 4.0 Перевод времени 2014
С двух часов ночи 26.10.2014 Москва стала жить по времени UTC+3.
Не претендую на абсолютную правильность, но предлагаю следующий способ, приведения MS CRM 4.0 в соответствие с реалиями. Нижеописанное решение лечит только один часовой пояс. Откатывается оно не сложно, но свежий бэкап еще никогда никому не мешал.
Итак, для перевода Москвы в зону UTC+3 нужно вручную нужно сделать следующие шаги:
1. Добавить определение для часового пояса Москвы ( TimeZoneCode 145 ), в таблицу TimeZoneRuleBase
2. Косметическое изменение названия этого же часового пояса в таблицах TimeZoneDefinitionBase и TimeZoneLocalizedNameBase
3. Установка корректного часового пояса и смещения времени для всех пользователей
4. Опциональный шаг для корректировки уже существующих дат в системе
Итак поехали,
1. Добавление определения для часового пояса Москвы
INSERT INTO [TimeZoneRuleBase]
([ModifiedBy]
,[StandardDay]
,[ModifiedOn]
,[StandardMinute]
,[StandardBias]
,[StandardYear]
,[DaylightMonth]
,[StandardDayOfWeek]
,[DaylightSecond]
,[Bias]
,[TimeZoneRuleVersionNumber]
,[DaylightBias]
,[StandardMonth]
,[EffectiveDateTime]
,[CreatedBy]
,[DaylightHour]
,[StandardHour]
,[CreatedOn]
,[DaylightYear]
,[StandardSecond]
,[DaylightMinute]
,[TimeZoneDefinitionId]
,[DaylightDayOfWeek]
,[TimeZoneRuleId]
,[DaylightDay]
,[OrganizationId]
,[DeletionStateCode])
VALUES
(NULL, --ModifiedBy, uniqueidentifier,
0, --StandardDay, int,
getutcdate(), --ModifiedOn, datetime, -- текущая дата
0, --StandardMinute, int,
0, --StandardBias, int,
0, --StandardYear, int,
0, --DaylightMonth, int,
0, --StandardDayOfWeek, int,
0, --DaylightSecond, int,
-180, --Bias, int, -- смещение времени
20, --TimeZoneRuleVersionNumber, int, -- номер версии
-60, --DaylightBias, int,
0, --StandardMonth, int,
'2014-11-01 06:00:00.000', --EffectiveDateTime, datetime, --дата и время, начиная с которой будет действовать правило
NULL, --CreatedBy, uniqueidentifier,
0, --DaylightHour, int,
0, --StandardHour, int,
getutcdate(), --CreatedOn, datetime, -- текущая дата
0, --DaylightYear, int,
0, --StandardSecond, int,
0, --DaylightMinute, int,
'F6A0CC2F-7EC6-4F34-9CCC-9C2029D23EBF', --TimeZoneDefinitionId, uniqueidentifier, -- 145 Moscow +4 -- идентификатор московского часового пояса
0, --DaylightDayOfWeek, int,
'', --TimeZoneRuleId, uniqueidentifier, -- сюда нужно подставить какой-нибудь свежесгенирированный GUID
0, --DaylightDay, int,
NULL, --OrganizationId, uniqueidentifier,
0) --,DeletionStateCode, int,)
2. Косметическое изменение названия
update dbo.TimeZoneLocalizedNameBase
set UserInterfaceName = '(GMT+03:00) Волгоград, Москва, Санкт-Петербург'
where TimeZoneLocalizedNameId = 'C10582F5-B8F5-40DC-9BDF-C2B62FEA7047'
update dbo.TimeZoneDefinitionBase
set UserInterfaceName = '(GMT+03:00) Moscow, St. Petersburg, Volgograd'
where [TimeZoneDefinitionId] = 'F6A0CC2F-7EC6-4F34-9CCC-9C2029D23EBF' -- 145 Moscow +4 -- тот самый свежесгенерированный GUID из п.1
3. Установка корректного часового пояса и смещения времени для всех пользователей
Осторожно, без условия where это изменение затронет вообще всех пользователей
update [vkpm_MSCRM].[dbo].[UserSettingsBase]
set TimeZoneBias = -180, TimeZoneCode = 145
4. Опциональный шаг для корректировки уже существующих дат в системе
Ниже пример sql запроса выправляющего конкретное поле, в котором может некорректно отображаться дата из-за того, что пользователь указал дату без времени будучи в поясе UTC+4, при этом в БД записалось значение: текущая_дата_минус_один_день 20:00. А после перевод пользователей в пояс UTC+3 в интерфейсе все такие даты будут уменьшены на один день, т.к. при прибавлении трех часов к значению в БД смены даты не происходит. Поэтому нужно прибавить минимум один час к датам после момента перевода, если они были введены в полях без отображения времени.
update new_entity
set new_date = DateAdd(hh,1,new_date)
where new_date > '2014-11-01 06:00:00.000' -- тут дата, с которой начинает действовать новое правило в TimeZoneRuleBase из п.1
Всё. Должно работать.
Не претендую на абсолютную правильность, но предлагаю следующий способ, приведения MS CRM 4.0 в соответствие с реалиями. Нижеописанное решение лечит только один часовой пояс. Откатывается оно не сложно, но свежий бэкап еще никогда никому не мешал.
Итак, для перевода Москвы в зону UTC+3 нужно вручную нужно сделать следующие шаги:
1. Добавить определение для часового пояса Москвы ( TimeZoneCode 145 ), в таблицу TimeZoneRuleBase
2. Косметическое изменение названия этого же часового пояса в таблицах TimeZoneDefinitionBase и TimeZoneLocalizedNameBase
3. Установка корректного часового пояса и смещения времени для всех пользователей
4. Опциональный шаг для корректировки уже существующих дат в системе
Итак поехали,
1. Добавление определения для часового пояса Москвы
INSERT INTO [TimeZoneRuleBase]
([ModifiedBy]
,[StandardDay]
,[ModifiedOn]
,[StandardMinute]
,[StandardBias]
,[StandardYear]
,[DaylightMonth]
,[StandardDayOfWeek]
,[DaylightSecond]
,[Bias]
,[TimeZoneRuleVersionNumber]
,[DaylightBias]
,[StandardMonth]
,[EffectiveDateTime]
,[CreatedBy]
,[DaylightHour]
,[StandardHour]
,[CreatedOn]
,[DaylightYear]
,[StandardSecond]
,[DaylightMinute]
,[TimeZoneDefinitionId]
,[DaylightDayOfWeek]
,[TimeZoneRuleId]
,[DaylightDay]
,[OrganizationId]
,[DeletionStateCode])
VALUES
(NULL, --ModifiedBy, uniqueidentifier,
0, --StandardDay, int,
getutcdate(), --ModifiedOn, datetime, -- текущая дата
0, --StandardMinute, int,
0, --StandardBias, int,
0, --StandardYear, int,
0, --DaylightMonth, int,
0, --StandardDayOfWeek, int,
0, --DaylightSecond, int,
-180, --Bias, int, -- смещение времени
20, --TimeZoneRuleVersionNumber, int, -- номер версии
-60, --DaylightBias, int,
0, --StandardMonth, int,
'2014-11-01 06:00:00.000', --EffectiveDateTime, datetime, --дата и время, начиная с которой будет действовать правило
NULL, --CreatedBy, uniqueidentifier,
0, --DaylightHour, int,
0, --StandardHour, int,
getutcdate(), --CreatedOn, datetime, -- текущая дата
0, --DaylightYear, int,
0, --StandardSecond, int,
0, --DaylightMinute, int,
'F6A0CC2F-7EC6-4F34-9CCC-9C2029D23EBF', --TimeZoneDefinitionId, uniqueidentifier, -- 145 Moscow +4 -- идентификатор московского часового пояса
0, --DaylightDayOfWeek, int,
'', --TimeZoneRuleId, uniqueidentifier, -- сюда нужно подставить какой-нибудь свежесгенирированный GUID
0, --DaylightDay, int,
NULL, --OrganizationId, uniqueidentifier,
0) --,DeletionStateCode, int,)
2. Косметическое изменение названия
update dbo.TimeZoneLocalizedNameBase
set UserInterfaceName = '(GMT+03:00) Волгоград, Москва, Санкт-Петербург'
where TimeZoneLocalizedNameId = 'C10582F5-B8F5-40DC-9BDF-C2B62FEA7047'
update dbo.TimeZoneDefinitionBase
set UserInterfaceName = '(GMT+03:00) Moscow, St. Petersburg, Volgograd'
where [TimeZoneDefinitionId] = 'F6A0CC2F-7EC6-4F34-9CCC-9C2029D23EBF' -- 145 Moscow +4 -- тот самый свежесгенерированный GUID из п.1
3. Установка корректного часового пояса и смещения времени для всех пользователей
Осторожно, без условия where это изменение затронет вообще всех пользователей
update [vkpm_MSCRM].[dbo].[UserSettingsBase]
set TimeZoneBias = -180, TimeZoneCode = 145
4. Опциональный шаг для корректировки уже существующих дат в системе
Ниже пример sql запроса выправляющего конкретное поле, в котором может некорректно отображаться дата из-за того, что пользователь указал дату без времени будучи в поясе UTC+4, при этом в БД записалось значение: текущая_дата_минус_один_день 20:00. А после перевод пользователей в пояс UTC+3 в интерфейсе все такие даты будут уменьшены на один день, т.к. при прибавлении трех часов к значению в БД смены даты не происходит. Поэтому нужно прибавить минимум один час к датам после момента перевода, если они были введены в полях без отображения времени.
update new_entity
set new_date = DateAdd(hh,1,new_date)
where new_date > '2014-11-01 06:00:00.000' -- тут дата, с которой начинает действовать новое правило в TimeZoneRuleBase из п.1
Всё. Должно работать.