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

[Владимир Максимов]

Цитата:

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

Если же идти по пути установки патча от Microsoft, в чём некорректность XML?

Я уже описал вот здесь Y2K11 или переход на зимнее время

Цитата:

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

А у коллег, которые уже исправляли у себя TimeZone решилась проблема с отображением modified, created?

Для полей ModifiedDateTime и CreatedDateTime временная зона не задается. Их значение всегда рассчитывается по текущей временной зоне сеанса данных. Это значит, что все времена окажутся "сдвинуты" на 1 час "назад", если использовать временные зоны из патча Microsoft. Он не корректен в отношении времени ДО 26.10.2014.

Впрочем, мои модификации тоже дадут корректное значение старых данных только до окончания 2014 года. Если использовать отдельное правило для 2015 года, то после 01.01.2015 данные о создании/изменении записей до 26.10.2014 тоже окажутся "сдвинуты" на 1 час назад

Цитата:

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

Владимир Максимов, Logger, помогите разобраться.

В блоге Владимир определяет, что
Поля D* - определят начальную дату и время для сдвига DST
Поле S* - определят конечную дату и время для сдвига DST

Тем не менее, в приложенном XML для 2014 года
smonth = 10
dmonth = 12

В чём идеология? Не надо ли поменять местами все поля s* и d*?

Специально не проверял, но как мне кажется, для Axapta это не имеет значения. Просто две границы. А какая из них будет началом, какая - концом, Axapta определит сама.

Лично я вводил данные "слева-направо". Поскольку поля S* оказались "слева", то я в них и ввел "начало". Если же посмотрите старые записи TimeZonesRulesData, то там сделано наоборот. D* - начало, а S* - конец.

По крайней мере, у меня все корректно "перевелось". Т.е. Axapta "поняла", что я ввел в S* - начало, а в D* - окончание диапазона.