axforum blogs: TimeZone в Ax2009

[Blog bot]

Источник: http://axforum.info/forums/blog.php?b=8151
==============

Ну, хорошо, новое правило определения TimeZone добавили. А что делает форма TimeZonePatcher? О каких таких "исправлениях" идет речь?

Для начала, надо разобраться с "физикой" процесса ;)

При создании полей на основе базового типа данных Types::UtcDateTime физически, на уровне базы данных создаются 2 поля:

1. Поле с типом DateTime хранящее время UTC
2. Поле, имя которого совпадает с именем поля DateTime, но с добавленным окончанием "TZID".

Поле *TZID является служебным и не отображется в среде Axapta. Хотя в таблице SqlDictionary присутствуют.

Например, в таблице BatchJob есть поле OrigStartDateTime, которое видно в списке полей этой таблицы в AOT. Но, кроме того, у этой же таблицы есть поле OrigStartDateTimeTZID, которое можно увидеть только на уровне базы данных SQL. В среде Axapta оно не видно

В поле *TZID записывается идентификатор временной зоны (TZID = Time Zone IDentifier). Таким идентификатором является значение поля таблицы TimeZonesRulesData.RuleID
Таблица TimeZonesRulesData это правила, определяющие "сдвиг" в минутах, который надо добавить (или вычесть) к значению поля DateTime


Логика чтения полей DateTime выглядит так:

1. Из поля DateTime считывается значение
2. Из поля *TZID считывается идентификатор правила чтения временных зон, определяется "сдвиг" в минутах и прибавляется к значению DateTime


Исключением из этого правила являются поля CreatedDateTime и ModifiedDateTime. Им в пару не создаются поля *TZID. Т.е. при их считывании всегда используется текущее правило "сдвига" времени в минутах.

Причина, по которой возникает необходимость "патчить" данные - это тот факт, что поле *TZID заполняется один раз в момент создания записи и больше уже не изменяется на протяжении всего времени существования записи.

Это значит, что если, например, до импорта новых правил определения временных зон Вы создадите пакетное задание, плановое дата/время которого будет, скажем, 01.11.2014 01:00:00, то, после импорта новых правил будет отображаться значение 01.11.2014 02:00:00. Почему? Да потому, что поле *TZID останется без изменений и будет ссылаться на правила расчета 2011 года. Т.е. добавлять к времени UTC (то, что сохранено в базе данных в поле DateTime) 4 часа, а не 3, как должно быть по новым правилам.

Следовательно, необходимо для всех дат, которые попали в область действия новых правил определения временных зон сделать замену:

1. В поле *TZID записать код записи нового правила
2. Поле DateTime увеличить на 1 час

Зачем добавлять 1 час? Так в базе данных записано время UTC. Т.е. без сдвига на 4 часа там хранится время 31.10.2014 21:00:00. Если к этому времени добавить 3 часа по новым правилам, то получим 01.11.2014 00:00:00, вместо ожидаемого 1 часа. Вот чтобы поясное время не изменилось, время UTC и надо увеличить на 1 час

Собственно, именно этим и занимается форма TimeZonePatcher.

После открытия этой формы надо выбрать обновляемое правила из списка (этот список заполняется и обновляется при импорте файла XML) и нажать кнопку "Загрузить все затронутые поля UtcDateTime". Этот процесс займет некоторое время (несколько минут), поскольку связан с перебором всех таблиц и определения факта наличия в них полей на базе UtcDateTime.

После того, как в нижней части формы отобразится список полей таблиц, Вам надо выбрать те поля, который Вы будете обновлять и нажать кнопку "Применить исправление"

--------------------------------------------------------

Ну, вроде все хорошо? "Счаззз"... У нас же обязательно какая-нибудь проблема вылезет ;)

Проблема заключается в том, что исправляются только те данные, которые попадают в область действия новых правил. В отношении правила 2014 года это не критично, поскольку он уже наступил. Просто импортируем файл XML с новыми правилами и запускаем форму TimeZonePatcher ДО наступления 26.10.2014 года. А вот с правилом 2015 года - есть проблема.

Если у Вас работают пакетные задания, то 01.01.2015 00:00:00 у всех них произойдет сдвиг запланированного времени исполнения на 1 час вперед. Почему? Так ведь у них по прежнему будет указан код *TZID относящийся к 2014 году. Как следствие, в январе сдвиг будет составлять 4 часа, а не 3 как необходимо.

Если для Вас сдвиг выполнени пакетных задний на 1 час не критичен, то этим можно пренебречь и выполнить запуск формы TimeZonePatcher после новогодних каникул 12 января. Если же это является проблемой, то следует поступить следующим образом:

1. В 2014 году импортируется только 1 правило, действующее с 26 октября 2014 кода и по 2153 год. Это импорт такого файла XML

PHP код:

61004
61
2014
-240
0
10
0
5
2
0
0
60
2153
12
3
5
23
59
59
0

Отличие от первоначального вариант - это тег 2153. Это значит, что 26.10.1014 произойдет сдвиг на 1 час вперед, но перевод на 1 час назад произойдет только в 2153 году. Т.е. в 2015 году по прежнему будет работать сдвиг на 3 часа.


2. После наступления 2015 года в любое удобное время необходимо на уровне SQL-сервера выполнить замену

PHP код:

update TimeZonesRulesData
set DYear = 0
where TzEnum = 61 and RULEID = 61004

и в Axapta импортировать файл XML с правилом на 2015 год

PHP код:

61005
61
2015
-180
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

3. После перезагрузки AOS запустить форму TimeZonePatcher для 2015 года


Источник: http://axforum.info/forums/blog.php?b=8151