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

[actNaturally]

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

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

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

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

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

Цитата:

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

[actNaturally]

Владимир, спасибо за ответ.

Получается, что возможности сделать так, чтобы начиная с 2015 года даты создания записанные до октября этого года отображались верно, у нас нет?

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

Цитата:

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

Владимир, спасибо за ответ.

Получается, что возможности сделать так, чтобы начиная с 2015 года даты создания записанные до октября этого года отображались верно, у нас нет?

Нет. Это я ошибся

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

При этом поле *TZID все-таки изменяется, если модификация поля выполняется из формы, а не из кода.

В результате, поля CreatedDateTime и ModifiedDateTime всегда будут отображаться корректно, если корректно настроены правила часовых поясов. В патче от Microsoft они корректны только начиная с 26.10.2014. Все старые данные будут отображаться не корректно.

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

Цитата:

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

ЗЫ Про добавку *TZID напоминать не надо.
Либо укажите, как ее можно использовать изнутри Аксапты (без внешних вызовов SQL)

Поле *TZID изменяется в том случае, если поле UTCDateTime модифицируется через форму. При программной модификации - не меняется. Можно ли на основании этого написать какой-то код по модификации *TZID из Axapta - не знаю.

[AndyD]

Цитата:

Сообщение от Владимир Максимов

Поле *TZID изменяется в том случае, если поле UTCDateTime модифицируется через форму. При программной модификации - не меняется. Можно ли на основании этого написать какой-то код по модификации *TZID из Axapta - не знаю.

Вообще, непонятное поле)

По-моему, его хотели как-то использовать, когда вводили, но, похоже, мысль умерла, а поле осталось)

[Vadik]

Цитата:

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

Это обновление ядра до версии 6.2.1000.9172

Что-то не вижу изменений после установки, Москва как была GMT+4 так и осталась

[gl00mie]

Цитата:

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

*TZID - вообще, непонятное поле) По-моему, его хотели как-то использовать, когда вводили, но, похоже, мысль умерла, а поле осталось)

Мысль не умерла - см. TimeZonePatcher. Если обновление настроек перехода на летнее/зимнее время для определенного часового пояса было применено уже после ввода данных (а данные могут относиться к будущим датам), поля *TZID позволяют постфактум идентифицировать данные, введенные именно в этом часовом поясе, и скорректировать их с учетом того, что при переводе из местного времени в UTC надо было, скажем, вычитать не 4, а 3 часа.

[Ivanhoe]

Цитата:

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

Что-то не вижу изменений после установки, Москва как была GMT+4 так и осталась

На одной из инсталляций аналогично, при этом появились какие-то "кривые" по названию зоны. Пробуем на других поставить, отпишусь.

[AndyD]

Цитата:

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

Что-то не вижу изменений после установки, Москва как была GMT+4 так и осталась

Если это мне адресуется, то ничего по этому поводу сказать не могу)
Тестировал на двух инсталляциях - таймзоны поменялись/новые добавились

Как вариант - на сервере АОСа установлено обновлений для таймзон Винды?

[AndyD]

Цитата:

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

Мысль не умерла - см. TimeZonePatcher. Если обновление настроек перехода на летнее/зимнее время для определенного часового пояса было применено уже после ввода данных (а данные могут относиться к будущим датам), поля *TZID позволяют постфактум идентифицировать данные, введенные именно в этом часовом поясе, и скорректировать их с учетом того, что при переводе из местного времени в UTC надо было, скажем, вычитать не 4, а 3 часа.

Это, конечно, замечательно)

Но вот только ничего подобно даже в интерфейсе я не вижу
Для всех полей дейттайм отображается пересчет в мою таймзону и ее правила, а не ту, что записана в TZID

И еще - в 2012-й патчер вообще упразднили
Видимо, за ненадобностью)

[actNaturally]

У кого есть опыт удаления загруженного нового правила тайм зон, поделитесь?)
Добавление ещё одного правила для того же самого года не срабатывает.

[AndyD]

Цитата:

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

А что нужно сделать в таблице TimeZonesList чтобы название нового часового пояса в лукапе было на русском языке ?

Вот здесь AX2009: Обновление по временным зонам MS советует заменить существующие записи

Но это неправильно для патча 2009-й).
Таймзоны новые добавились, так что надо не заменить, а добавить после записи "(GMT-04:30) Каракас" новые строчки

(GMT+02:00) Калиниград (RTZ 1)
(GMT+03:00) Волгоград, Москва, Санкт-Петербург (RTZ 2)
(GMT+04:00) Ижевск, Самара (RTZ 3)
(GMT+05:00) Екатеринбург (RTZ 4)
(GMT+06:00) Новосибирск (RTZ 5)
(GMT+07:00) Красноярск (RTZ 6)
(GMT+08:00) Иркутск (RTZ 7)
(GMT+09:00) Якутск (RTZ 8)
(GMT+10:00) Владивосток, Магадан (RTZ 9)
(GMT+11:00) Чокурдах (RTZ 10)
(GMT+12:00) Анадырь, Петропавловск-Камчатский (RTZ 11)

Если вы меняли существующие таймзоны - тогда на будет изменить название

В 2012-й соответствующие строчки необходимо изменить, а для трех новых - добавить после таймзоны "(GMT+01:00) Триполи"

(GMT+11:00) Чокурдах (RTZ 10)
(GMT+12:00) Анадырь, Петропавловск-Камчатский (RTZ 11)
(GMT+04:00) Ижевск, Самара (RTZ 3)

Добавлять именно в таком порядке

Изменения необходимо вносить в файлы AxSys*.ktd папки BIN клиента Аксапты на соответствующем языке (* - язык: ru, en-us и т.д.)
На сервере так же можно сделать эти изменения, но после сохранения файла необходимо будет удалить соответствующий файл *.kti из папки KTI. После старта AOS'а он восстановится

Для 2009-й будет выглядеть примерно так

[AndyD]

Цитата:

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

На одной из инсталляций аналогично, при этом появились какие-то "кривые" по названию зоны. Пробуем на других поставить, отпишусь.

А аналогично - это как?
В названии осталось GMT+4 или именно часы на +4 все равно показывают?
И "кривые" - это непонятный символ в названии?

Если дело только в названии, то смотри сообщение выше об изменении KTD

[Damn]

Цитата:

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

Как вариант - на сервере АОСа установлено обновлений для таймзон Винды?

Установил сначала обновление KB3012219 на Ax2012 R2, а потом обновление часовых поясов на Windows, на котором стоит АОС.
Функция DateTimeUtil::getClientMachineTimeZone() теперь возвращает ошибку "Часовой пояс, на который настроен компьютер не был найден в списке поддерживаемых часовых поясов.". Между установками обновлений аксапты и windows эта ошибка не возникала.

[AndyD]

У вас не английская версия винды с установленным русским MUI?

[AndyD]

Цитата:

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

а потом обновление часовых поясов на Windows, на котором стоит АОС

А где клиента запускаете - там обновление таймзон Windows установлено?

[Damn]

Цитата:

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

У вас не английская версия винды с установленным русским MUI?

Следите за мной что ли ?
Да, похоже так и есть. Интерфейс в операционке русскоязычный. А сама операционная система изначально была английской. Давнишний тестовый сервер, поэтому такие извращения.
Клиента запускаю на АОСе.

[AndyD]

Не подглядываю)), но в свое время мне с такой виндой повозиться пришлось

На самом деле, и до установки обновлений для таймзон были проблемы на такой конфигурации. Причем, как у 2012-й Аксапты, так и 2009-й

Как выяснилось, все дело в том, как сохраняется название таймзоны в реестре (значения для Std и Dlt).
Оно должно совпадать с языком интерфейса (с точки зрения клиента Аксапты, хотя, как видно из той же ветки реестра, эти названия хранятся в языковой dll как ресурсы).

Для новой таймзоны Москвы соответствие такое
"Russia TZ 2 Standard Time" -> "RTZ 2 (зима)"
"Russia TZ 2 Daylight Time"->"RTZ 2 (лето)"

В приложенной картинке приведены все названия таймзон на русском и соответствующие им на английском. Взяты из ресурсов файлов tzres.dll.mui языков ru-Ru и en-Us

Кстати, отсюда видно, что зоны Калининграда и Минска разделены.
Но в Аксапте Минск вообще проигнорировали

PS Не совсем понятно, как соответствие имен должно вести себя, если на терминальном сервере настроят разный языковый интерфейс для разных пользователей)). Есть подозрение, что не взлетит

[AndyD]

Обновление для 2012 R3 включено в CU8

Но, все данные по таймзонам соответствуют странным исправлениям для R2.
KTD так же не удосужились подправить