Цитата:
Сообщение от
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* - окончание диапазона.