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

[sukhanchik]

Цитата:

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

Не понятно)

Патч не был установлен, но все равно, часы в Аксапте перевелись?
Так?

А о какой версии идет речь?
О 2009-й?

Просто, я ничего подобно не наблюдаю)
Две инсталляции 2009-й Аксапты: на одной из них патч установлен, на другой - нет
Соответственно, без патча нет новых зачений енума, а по старому - нет перевода часов

Ну вот у меня как. 2 инсталляции. На одной с патчем, на другой без патча. После установке патча дата сеанса (до перевода часов) стала отставать. После перевода часов - все выровнялось.

На самом деле - я думаю - ответом является сравнение содержимого XML-файла и таблички TimeZonesRulesData. В моем случае - значение в поле BIAS у 61-го значения енума совпадало со значением из XML-файла.

Енум TimeZone на самом деле не енум - а лукап из таблицы TimeZonesList. Добавляем записи в TimeZonesList, рестартуем АОС - и оппа... енум TimeZone расширился

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

Форма TimeZonePatcher работает... только если загружаемый файл имеет новые правила для уже существующих зон. А если зоны новые - то она не работает. Поэтому я изменил XML-файлик под существующие зоны и его закачал. И результат сравнил с "непатченной" АХ. Вот прошел перевод стрелок... и никто "не вякнул". Ядро 5.0.1600.2983

Скриншот

[Damn]

Цитата:

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

Енум TimeZone на самом деле не енум - а лукап из таблицы TimeZonesList. Добавляем записи в TimeZonesList, рестартуем АОС - и оппа... енум TimeZone расширился

Форма TimeZonePatcher работает... только если загружаемый файл имеет новые правила для уже существующих зон. А если зоны новые - то она не работает. Поэтому я изменил XML-файлик под существующие зоны и его закачал. И результат сравнил с "непатченной" АХ. Вот прошел перевод стрелок... и никто "не вякнул". Ядро 5.0.1600.2983

А что нужно сделать в таблице TimeZonesList чтобы название нового часового пояса в лукапе было на русском языке ?
Можно попросить изменённый файлик ? В нём некоторые часовые пояса пришлось оставить новыми ? Существующих таких нет. Самара, например.

[sukhanchik]

Цитата:

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

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

Не знаю. Самому интересно . Но я просто решил оставить тот же код енума (т.е. старый часовой пояс), просто изменить остальные поля в табличке TimeZonesRulesData

Цитата:

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

Можно попросить изменённый файлик ? В нём некоторые часовые пояса пришлось оставить новыми ? Существующих таких нет. Самара, например.

А там ничего интересного в нем нет. Я выбросил новые зоны (чего-то не смогла с ними АХ "подружиться"; а бизнес-потребности в них нет). А в старых зонах - я оставил старый код енума и на 1 сдвинул параметр RuleId.

PHP код:

  <!-- Russia Time Zone 2 new rules -->
  <Timezonedata>
    <Timezone>
      <tzenum>61</tzenum>
      <timezonekeyname>RUSSIA TIME ZONE 2</timezonekeyname>
      <enumname>GMTPLUS0300MOSCOW_STPETERSBURG_VOLGOGRAD</enumname>
      <enumposition>61</enumposition>
    </Timezone>
    <Timezonerule>
      <ruleid>61002</ruleid>
      <tzenum>61</tzenum>
      <year>2014</year>
      <bias>-180</bias>
      <syear>0</syear>
      <smonth>0</smonth>
      <sdayofweek>0</sdayofweek>
      <sday>0</sday>
      <shour>3</shour>
      <sminute>0</sminute>
      <ssecond>0</ssecond>
      <sbias>0</sbias>
      <dyear>0</dyear>
      <dmonth>10</dmonth>
      <ddayofweek>0</ddayofweek>
      <dday>4</dday>
      <dhour>0</dhour>
      <dminute>0</dminute>
      <dsecond>0</dsecond>
      <dbias>-60</dbias>
    </Timezonerule>
  </Timezonedata> 


Позже, при импорте - пришлось подправить метод \Classes\TimeZoneImportHelper\importTimeZonePatches, чтобы система захотела именно обновить данные (параметр isNewTz д.б. false). Потому что иначе форма не отработает.

В общем, какого-то "универсального" решения у меня не получилось - но у меня оно "как-то само" заработало . Ну и ... я решил не париться.

[Damn]

Цитата:

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

пришлось подправить метод \Classes\TimeZoneImportHelper\importTimeZonePatches, чтобы система захотела именно обновить данные (параметр isNewTz д.б. false). Потому что иначе форма не отработает.

Править метод не надо. Нужно просто из файла выкинуть блоки "TimeZone":

    <Timezone> 
      <tzenum>61</tzenum> 
      <timezonekeyname>RUSSIA TIME ZONE 2</timezonekeyname> 
      <enumname>GMTPLUS0300MOSCOW_STPETERSBURG_VOLGOGRAD</enumname> 
      <enumposition>61</enumposition> 
    </Timezone>

Для добавления новых TimeZoneRule эти блоки не нужны.

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

Цитата:

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

Но я просто решил оставить тот же код енума (т.е. старый часовой пояс), просто изменить остальные поля в табличке TimeZonesRulesData

Угу. Я также поступил...

Цитата:

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

Я выбросил новые зоны (чего-то не смогла с ними АХ "подружиться"; а бизнес-потребности в них нет). А в старых зонах - я оставил старый код енума и на 1 сдвинул параметр RuleId.

(...)

Позже, при импорте - пришлось подправить метод \Classes\TimeZoneImportHelper\importTimeZonePatches, чтобы система захотела именно обновить данные (параметр isNewTz д.б. false). Потому что иначе форма не отработает.

Это потому, что Ваш XML содержит ряд ошибок. Он не корректен. Точно также, как не корректен XML в патче от Microsoft. Зря Вы его использовали в качестве образца...

Цитата:

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

В общем, какого-то "универсального" решения у меня не получилось - но у меня оно "как-то само" заработало . Ну и ... я решил не париться.

Вообще-то, есть. Выше были даны ссылки на мой блог. Лично у меня все получилось Я действовал именно так, как описано в блоге. Никаких проблем не возникло при переходе. Причем я накатил новый XML (собственного производства) еще месяц назад

[actNaturally]

Добрый день,

Цитата:

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

Вообще-то, есть. Выше были даны ссылки на мой блог. Лично у меня все получилось Я действовал именно так, как описано в блоге. Никаких проблем не возникло при переходе. Причем я накатил новый XML (собственного производства) еще месяц назад

Владимир, если не затруднит, продублируйте ссылки, пожалуйста, в упор не вижу!

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

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

[Logger]

Цитата:

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

Владимир, если не затруднит, продублируйте ссылки, пожалуйста, в упор не вижу!

http://axforum.info/forums/blog.php?b=8150
http://axforum.info/forums/blog.php?b=8151

[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 года даты создания записанные до октября этого года отображались верно, у нас нет?

[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-й будет выглядеть примерно так

[Logger]

Цитата:

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

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

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

AndyD, а не поделитесь файлом который у вас получился ?
Вылезли аналогичные проблемы на ax2012 R3 под 2012-й виндой.

DateTimeUtil::getClientMachineTimeZone() - выводит ерунду какую-то "(GMT+03:00) Кувейт, Эр-Рияд" значение енума = 3
А в настройках винды стоит зона "Москва, Волгоград".
Похоже MUI гадит. Или MUI в сочетании с недоделанным ktd файлом.
Без MUI все ок.

Ax2012 R3 CU9