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


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

В этой теме 23 ответа, 9 участников, последнее обновление  Антон Чевычалов 5 года/лет, 2 мес. назад.

Aliexpress INT
  • Автор
    Сообщения
  • #13777

    kir
    Хранитель
    Aliexpress INT

    [article]418[/article]

  • #13778

    andrewk
    Участник

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

  • #13779

    Valery Gruzdev
    Участник

    🙂
    Активные участники Технологического клуба могли заметить. что информация была размещена много раньше. http://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
    Участник

    🙂
    Активные участники Технологического клуба могли заметить. что информация была размещена много раньше. http://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 (я пока не проверял).

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

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