Подготовка к отмене перехода на зимнее время

Главная Форумы Обсуждение материалов портала Подготовка к отмене перехода на зимнее время

Просмотр 23 веток ответов
  • Автор
    Сообщения
    • #13777
      kir
      Хранитель

      [article]418[/article]

    • #13778
      andrewk
      Участник

      IBM как всегда своевременно реагирует на нужды клиентов – за 3 дня до часа Х.

    • #13779
      Valery Gruzdev
      Участник

      🙂
      Активные участники Технологического клуба могли заметить. что информация была размещена много раньше. https://aixportal.ru/новости/415–29-.html

      И есть еще время…. Если остались вопросы по теме – пишите-звоните, СРОЧНО !

    • #13780
      Sever
      Участник

      IMHO сейчас IBMу нужно готовить инструкцию по плану действий для тех, кто не успеет сделать каких либо изменений и столкнется с “некоректным” временем после часа Х.

      Ответственность за проблемы клиентов, которые возникнут у многих, целиком лежит на IBM. Причины:
      – Отсутствие какой либо активности по этому вопросу в Московском IBM весной и летом;
      – Отсутствует мотивации на превентивное устранение потенциальных проблем у заказчиков;
      – Отсутствие жесткой позиции в отстаивании интересов российских клиентов внутри компании.

    • #13781

      p630 AIX 5.2 зона MSK+2 (Екатеринбургское время)

      изучили презентацию с технологического клуба, установили в /etc/environment TZ=STD-6, перезагрузились, пока всё нормально 😉

    • #13790

      Ответственность за проблемы клиентов, которые возникнут у многих, целиком лежит на IBM.

      Поддерживаю. Такого от ibm я не ожидал – только довольно жесткое общение с западными разрабами позволило получить efix. Российское отделение вообще фактически устранилось от проблемы (по крайне мере так это выглядит со стороны).

    • #13792

      Осталось чуть больше суток до момента истины…

    • #13794
      andrewk
      Участник

      🙂
      Активные участники Технологического клуба могли заметить. что информация была размещена много раньше. https://aixportal.ru/новости/415–29-.html

      И есть еще время…. Если остались вопросы по теме – пишите-звоните, СРОЧНО !

      а активные участники aixportal’a могли заметить, что проблема здесь обсуждалась и решение было предложено еще раньше 😉

    • #13795
      Valery Gruzdev
      Участник

      Полез на сайт поддержки…
      По всем признакам Сервис пак от 21.10.11 должен содержать обновленную тайм зону для AIX 6.1

      “…APARTXT IV05091 = Update of 6.1 Global timezone data
      Olson Time zone may not be changed correctly in
      some countries.
      APARTXT IV05100 = Update to ICU4C time zone data for Russia.
      The customer will have the wrong standard time for Russia when
      using applications dependant on the ICU4C library.”

      Должно быть и для 7.1 от 17.10.11, в bff правла не видно, попробовать еще не успел…

      Кто-ниб в сервис ходил пследнее время ? Устанавливал сервис пак 6.1 ? 7.1 ? Что вышло ?

    • #13796
      andrewk
      Участник

      у меня стоит:

      $ oslevel -s
      7100-00-03-1115

      $ zdump -v Europe/Moscow | grep 2011
      Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0
      Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSD isdst=1
      Europe/Moscow Sat Oct 29 22:59:59 2011 UTC = Sun Oct 30 02:59:59 2011 MSD isdst=1
      Europe/Moscow Sat Oct 29 23:00:00 2011 UTC = Sun Oct 30 02:00:00 2011 MSK isdst=0

      TL1 еще не пробовал. Завтра попробую его поставить, посмотрю.

    • #13797
      yota
      Участник

      [root@n1 /]# oslevel -s
      7100-01-01-1141
      [root@n1 /]# zdump -v Europe/Moscow | grep 2011
      Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0
      Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSD isdst=1
      Europe/Moscow Sat Oct 29 22:59:59 2011 UTC = Sun Oct 30 02:59:59 2011 MSD isdst=1
      Europe/Moscow Sat Oct 29 23:00:00 2011 UTC = Sun Oct 30 02:00:00 2011 MSK isdst=0

      Чуть попозже будет результат для 6100-07-01-1141.

    • #13799
      yota
      Участник

      # oslevel -s
      6100-07-01-1141

      # zdump -v Europe/Moscow | grep 2011
      zdump: warning: zone “Europe/Moscow” abbreviation “GMT+04:00” differs from POSIX standard
      Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 GMT+04:00 isdst=0

      Как бы все хорошо. Но…

      # zdump -v Europe/Moscow
      Europe/Moscow Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:15:52 1901 GMT+04:00 isdst=0
      zdump: warning: zone “Europe/Moscow” abbreviation “GMT+04:00” differs from POSIX standard
      Europe/Moscow Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:15:52 1901 GMT+04:00 isdst=0
      Europe/Moscow Sun Jul 2 21:29:59 1916 UTC = Sun Jul 2 23:59:59 1916 GMT+04:00 isdst=0
      Europe/Moscow Sun Jul 2 21:30:00 1916 UTC = Mon Jul 3 00:00:48 1916 GMT+04:00 isdst=0
      Europe/Moscow Mon Jun 30 21:29:11 1919 UTC = Mon Jun 30 23:59:59 1919 GMT+04:00 isdst=0
      Europe/Moscow Mon Jun 30 21:29:12 1919 UTC = Tue Jul 1 00:29:12 1919 GMT+04:00 isdst=0
      Europe/Moscow Sat Sep 30 20:59:59 1922 UTC = Sat Sep 30 23:59:59 1922 GMT+04:00 isdst=0
      Europe/Moscow Sat Sep 30 21:00:00 1922 UTC = Sat Sep 30 23:00:00 1922 GMT+04:00 isdst=0
      Europe/Moscow Fri Jun 20 21:59:59 1930 UTC = Fri Jun 20 23:59:59 1930 GMT+04:00 isdst=0
      Europe/Moscow Fri Jun 20 22:00:00 1930 UTC = Sat Jun 21 01:00:00 1930 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 30 22:59:59 1991 UTC = Sun Mar 31 01:59:59 1991 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 30 23:00:00 1991 UTC = Sun Mar 31 01:00:00 1991 GMT+04:00 isdst=0
      Europe/Moscow Sat Jan 18 23:59:59 1992 UTC = Sun Jan 19 01:59:59 1992 GMT+04:00 isdst=0
      Europe/Moscow Sun Jan 19 00:00:00 1992 UTC = Sun Jan 19 03:00:00 1992 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 GMT+04:00 isdst=0
      Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 GMT+04:00 isdst=0
      Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Sat Dec 14 00:45:51 1901 GMT+04:00 isdst=0

      [strike]Чо за херня?[/strike] WTH??

    • #13801
      Valery Gruzdev
      Участник

      # oslevel -s
      6100-07-01-1141
      ….
      # zdump -v Europe/Moscow
      ……
      Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 GMT+04:00 isdst=0
      Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Sat Dec 14 00:45:51 1901 GMT+04:00 isdst=0

      [strike]Чо за х…?[/strike] WTH??

      :silly: :blush:

      AIX 7.1, значит, пока не исправили… т.е. действуем по ранее утвержденному плану.

      AIX 6.1 – молодцы, конечно, оперативно поработали, и если поставить фикс, то вообщем проблема осени 2011 будет решена.
      Но 2038 ! Это ж надо ! Ну ладно 18.01.38 время поменяется, но 19.01.38 – все вместе перключается в 1901г….

      Успокаивает, что до 2038 еще далеко, и там либо ишак, либо падишах…., либо все таки все-таки пофиксят 6.1 норамльно.

      Если серъезно – это мусор там какой-то. Я так полагаю, что все-таки пофиксили 6.1, и этот мусор никак не скажется на показаниях времени влоть до января 2038.

    • #13802

      В 32-битных линуксах тоже 2038 есть, и в солярисах есть.

    • #13803
      yota
      Участник

      Да дело не только в 38 годе. Прикол в том, что после этого “патча” получается что у нас вообще никогда летнего времени не было :laugh: Это просто издевательство какое то, похоже этот патч какой то криворукий индус делал, что называется на @#$%ись.

    • #13804
      andrewk
      Участник

      да btw проблема 2038 г. официально пофиксена в AIX 7.1 TL1 🙂

    • #13805
      Sever
      Участник

      Проблема 38го года официально заложена.

    • #13806

      Кстати да, я не обратил внимание, опять же, в отличии от линуксового/солярного, где isdst пропало только в 2011-м году…

    • #13813
      Denis Yakimov
      Участник

      Вот есть такой старичок в моем зоопарке

      cat /etc/redhat-release
      Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

      zdump -v “Europe/Moscow” | tail -3
      Europe/Moscow Sat Oct 24 23:00:00 2037 UTC = Sun Oct 25 02:00:00 2037 MSK isdst=0 gmtoff=10800
      Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 06:14:07 2038 MSK isdst=0 gmtoff=10800
      Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 06:14:07 2038 MSK isdst=0 gmtoff=10800

      Тоже заканчивается 38-ым годом.
      Это очень все похоже на хвост, растущий из самой Olson. 🙂

      Кстати, эта Olson все еще поддерживается? Или автора таки засудили?

    • #13815

      Это не Олсон, это проблема 2038 – переполнение 32-битной переменной под Unix время

    • #13817

      Сегодня столкнулись с проблемой TZ у HP ServiceDesk 4.5. В некоторых местах, но не везде, вылезло смещение в 1 час. Проапдейтили TZ в Java в соответствии с рекомендациями Oracle и всё заработало как надо.

    • #13831
      Valery Gruzdev
      Участник

      Вот тут есть довольно подробные описания, как проапдэйтить timezone для IBM Java (на POWER, например).

      Общее описание: http://www.ibm.com/developerworks/java/jdk/dst/index.html
      Таблица обновлений Olson : http://www.ibm.com/developerworks/java/jdk/dst/olson_table.html
      Инструкции, как обновить Java для различных платформ: http://www-01.ibm.com/support/docview.wss?uid=swg21251761
      Ссылка для скачивания утилиты JTZU (Java TZ Update, если нет возможности установит update для Java): http://www.ibm.com/developerworks/java/jdk/dst/jtzu.html

    • #13909

      Да дело не только в 38 годе. Прикол в том, что после этого “патча” получается что у нас вообще никогда летнего времени не было :laugh: Это просто издевательство какое то, похоже этот патч какой то криворукий индус делал, что называется на @#$%ись.

      Похоже это баг отображения, поскольку при возврате все отображается нормально:

      [code]
      root@rdbms_test [2] ~
      [Thu 10.11.2011 16:26:05] date; date -u
      Thu Nov 10 16:26:09 GMT+04:00 2011
      Thu Nov 10 12:26:09 GMT 2011

      root@rdbms_test [2] ~
      [Thu 10.11.2011 16:26:09] zdump -v Europe/Moscow
      Europe/Moscow Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:15:52 1901 GMT+04:00 isdst=0
      zdump: warning: zone “Europe/Moscow” abbreviation “GMT+04:00” differs from POSIX standard
      Europe/Moscow Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:15:52 1901 GMT+04:00 isdst=0
      Europe/Moscow Sun Jul 2 21:29:59 1916 UTC = Sun Jul 2 23:59:59 1916 GMT+04:00 isdst=0
      Europe/Moscow Sun Jul 2 21:30:00 1916 UTC = Mon Jul 3 00:00:48 1916 GMT+04:00 isdst=0
      Europe/Moscow Mon Jun 30 21:29:11 1919 UTC = Mon Jun 30 23:59:59 1919 GMT+04:00 isdst=0
      Europe/Moscow Mon Jun 30 21:29:12 1919 UTC = Tue Jul 1 00:29:12 1919 GMT+04:00 isdst=0
      Europe/Moscow Sat Sep 30 20:59:59 1922 UTC = Sat Sep 30 23:59:59 1922 GMT+04:00 isdst=0
      Europe/Moscow Sat Sep 30 21:00:00 1922 UTC = Sat Sep 30 23:00:00 1922 GMT+04:00 isdst=0
      Europe/Moscow Fri Jun 20 21:59:59 1930 UTC = Fri Jun 20 23:59:59 1930 GMT+04:00 isdst=0
      Europe/Moscow Fri Jun 20 22:00:00 1930 UTC = Sat Jun 21 01:00:00 1930 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 30 22:59:59 1991 UTC = Sun Mar 31 01:59:59 1991 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 30 23:00:00 1991 UTC = Sun Mar 31 01:00:00 1991 GMT+04:00 isdst=0
      Europe/Moscow Sat Jan 18 23:59:59 1992 UTC = Sun Jan 19 01:59:59 1992 GMT+04:00 isdst=0
      Europe/Moscow Sun Jan 19 00:00:00 1992 UTC = Sun Jan 19 03:00:00 1992 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 GMT+04:00 isdst=0
      Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 GMT+04:00 isdst=0
      Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 GMT+04:00 isdst=0
      Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Sat Dec 14 00:45:51 1901 GMT+04:00 isdst=0

      root@rdbms_test [2] ~
      [Tue 11.10.2011 16:36:16] date 1110163410
      Wed Nov 10 16:34:25 GMT+04:00 2010

      root@rdbms_test [2] ~
      [Wed 10.11.2010 16:34:25] date; date -u
      Wed Nov 10 16:34:33 GMT+03:00 2010
      Wed Nov 10 13:34:33 GMT 2010

      [/code]

    • #15998

      Я вот по этой проблеме с zdump заводил pmr 8 месяцев назад и, вы таки не поверите, получил ответ: это проблема zdump и она устранена в TL7 для 6.1 (я пока не проверял).

      Это я так, для истории и индексации гуглом.

Просмотр 23 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.