Пользователь
30,2
рейтинг
15 января 2015 в 18:07

Разработка → 30 июня 2015 г. будет на секунду длиннее

Международная служба вращения Земли уведомляет, что к июню 2015 года добавляется положительная секунда координации. Последовательность будет такой:

30.06.2015 23 ч 59 мин 59 с
30.06.2015 23 ч 59 мин 60 с
01.07.2015 00 ч 00 мин 00 с

Разница между UTC и международным атомным временем:

с 01.07.2012 00 ч UTC до 01.07.2015 00 ч UTC: UTC-TAI = -35 с
с 01.07.2015 00 ч UTC до дальнейшего уведомления: UTC-TAI = -36 с

Секунды координации с 1972 года добавляются к декабрю или июню, чтобы время UTC не отличалось от UT1 более, чем на 0,9 с.

Линус Торвальдс сказал, что разработчики ядра не ожидают никаких проблем с Linux в этом году, но проблемы обязательно будут, потому что каждый раз при добавлении секунды координации проявляется что-то новое. Ситуация очень редкая, поэтому нельзя нормально протестировать её.

Спор об отмене секунды координации продолжается уже 15 лет. Возможно, проблему решат в ноябре нынешнего года на Всемирной конференции по радиосвязи в Женеве. На отмене leap second настаивают представители США, некоторые эксперты ITU и др. Впрочем, дебаты могут затянуться ещё на пару десятилетий.
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (56)

  • +7
    Раз уж написали статью на хабр, может обьяснительные ссылки о проблеме хотя бы приведете? Я вот вообще не в теме, но мне очень любопытно.
    • +3
      Это называется leap second, UTC это апроксимация UT1 (которое вычисляется астрономическими рассчетами), поэтому время от времени требуется корректировка.
    • +3
      У нас был такой баг: делали cond_wait (или epoll, не помню точно) с временем ожидания в 1 секунду, он сразу завершался как будто с таймаутом, в итоге 1 ядро процессора съедали на 100%. JVM вообще падала :) Лечились все проблемы перезагрузкой или хитрой манипуляцией с датой-временем на машине.
      • 0
        Угу, спасибо IERS, опять придётся перезапускать сервер.
    • +4
      • 0
        Мы когда админа на Debian искали, так один из «коварных» вопросов был сколько секунд в минуте. Кстати, не все вспоминали.
        Глядишь, после лета 2015-го вопрос опять будет актуальным.
        • 0
          ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BB%D0%BD%D0%B5%D1%87%D0%BD%D1%8B%D0%B5_%D1%81%D1%83%D1%82%D0%BA%D0%B8
          ru.wikipedia.org/wiki/%D0%97%D0%B2%D1%91%D0%B7%D0%B4%D0%BD%D1%8B%D0%B5_%D1%81%D1%83%D1%82%D0%BA%D0%B8

          Всё же чутка разные вещи, т.ч. разумно что некоторые смотрели на вас как ни идиотов, но в целом вопрос для проверки общего развития неплох, к ИТ же имеет крайне посредственное отношение кроме подобных ситуация с переводом на секунду, но и тут же каждый не будет сидеть и переводить время, linux выпустят патч, java тоже, ну и т.п., больше вендорная задача, т.ч. такие знания в ежедневных применениях нужны достаточно узкому кругу лиц, ну и к тому же развитый человек сможет изучить данный вопрос и сделать выводы, т.ч. в принципе вопрос как профессиональный вообще ничего не стоит, как посмотреть на развитие человека в очень узкой области нормальный.
    • 0
      Таки тоже ни хрена не понял: нам ntp-сервера UTC, которое по time(0) выдаётся, на секунду задержат или просто оно от международного атомного времени будет ещё больше отставать? Если второе, то почему у людей в прошлый раз системы висли?
      • 0
        Я так понимаю npt будет выдавать дубли в эту самую секунду
      • 0
        Первое, первое, читайте Википедию, ищите в инете и т. д. И на идеальной операционной системе, соответствующей всем стандартам, команда date должна в определённый момент выдать 23:59:60, хотя, не факт, что реальный date этим стандартам соответствует
        • 0
          date просто форматирует unix time, который в теории представляет собой целое число секунд, прошедших с полуночи по UTC 1 января 1970г. Оказывается, это не так, поскольку господа координаторы сдвигают время, раз в несколько лет скрывая по секунде, что на мой взгляд абсолютно неверно, потому что реальный интервал между датами/временем будет больше, чем просто разница между переведёнными в time_t. А если нужно отслеживать точные интервалы, придётся обрабатывать такие события, вместо того, чтобы просто учитывать эти секунды при форматировании дат, как учитываются часовые пояса с летним временем и високосными годами.

          Насчёт Википедии и поиска в Инете: Хабр всё-таки не просто новостной ресурс, IMHO в статье должны быть хотя бы ссылки на материалы, а главное — нормально рассмотрены последствия для типовых PC и серверов (Windows и Linux).
          Поведение NTP-серверов описано здесь. Часы поручиков стоят одну секунду.
  • +43
    «Международная служба вращения Земли» — классное название.
    • +19
      Я так назову свою следующую рок-группу.
    • +47
      Основной штат — медведи!
      • –7
        Ну вот. Теперь я вспомнил «Песню про медведей» из «Кавказской пленницы».
    • +11
      Вращаем Землю с 1972 года.
      • +22
        Вертим… :)
        • +2
          Я даже не буду спрашивать на чем! о_О
          • +4
            т.е. вопроса «чем?» даже не возникает?
          • 0
            На оси, естественно
            • –2
              — «Да я вашу Землю на оси вертел!»
    • 0
      Первое, что пришло в голову: «Ого. Есть даже специальная служба про это!»
      Второе: «Чем, интересно, эта служба занимается-то вообще?»
  • +7
    Ну только с таймзонами разобрались =((
  • +3
    Интересно много ли программ рассчитано на 61 секунду в минуте. Атомные часы таки тоже спешат.
    • 0
      Там таки без разницы — главное, чтобы интервалы стабильные были, а отображение абсолютных значений всегда можно настроить.
    • +1
      А программам-то что? Время синхронизируется сверху, как будто внутренние часы отстали на секунду. Подавляющая часть it-сектора даже не заметит.
      Возможно проблемы будут у каких-нибудь распределённых систем.
      • 0
        Могут быть проблемы в выводе и форматировании. Например, кто-то хочет в бд записать время в TZ-нотации, пишет 23:59:60, а ему говорят «неверно!» и программа сворачивается в неожиданном месте.

        То есть те, кто время считают, вероятнее всего, не заметят. А вот те, кто вводят/выводят данные, могут получить неожиданности. Например (гипотетически) реактор решит, что пора опускать стержни и надо это сделать через минуту. ПО берёт текущую дату, добавляет минуту, и начинает в poll-режиме ждать, когда станет 61 секунда следующей минуты. И ждёт, и ждёт…
        • 0
          В смысле, если будет перескок через секунду? То есть так же, как с переводом на час с 2:00 на 3:00, когда например 2:30 просто не будет?
          • 0
            Я спекулирую. Такой sleep, это, конечно, с одной стороны антиутопия, с другой стороны я тут посмотрел, как freebsd автоматизируют в облаках… Кормить её timed scan codes на консоль — в тыщу раз хуже expect'а, однако, best practice. Возможно у кого-то со временем то же самое.

            А вот ошибки приведения при таких секундах — суровая реальность.

            Собственно, пример бага (python):

            >>> time.ctime(time.mktime((2015,06,30, 23, 60, 00, 0, 0, -1)))
            'Wed Jul 1 00:00:00 2015'
        • 0
          Обещается же, что будет возвращаться время без этой секунды, будет 59-я секунда в течении двух секунд.
          Может стоит за минуту до этого сервера и перегрузить планово… хотя для всех сразу…
      • +1
        Считаем скорость чего-нить: измеряем путь пройденный за секунду и делим на разницу времени (23:59:59-23:59:59), ну, а дальше зависит от нашей удачи.
  • 0
    И сколько они уже этих секунд надобавляли?
    • +1
      Пост не читай
      @@@
      Комментарий пиши

      с 01.07.2012 00 ч UTC до 01.07.2015 00 ч UTC: UTC-TAI = -35 с
      с 01.07.2015 00 ч UTC до дальнейшего уведомления: UTC-TAI = -36 с
      • +2
        А где сказано, что это всё и есть добавленные секунды?
      • +4
        Википедия читай . Пока 25сек.
        Интересное решение добавить один час через 6000лет.
  • 0
    del
    • 0
      Интересно то, что секунда может и вычитаться, но такого еще не было, поскольку вращение Земли сейчас замедляется.
      • +4
        Так, может, надо не секунду прибавлять, а Землю уже подкрутить?
        • +6
          И правда, чем там в этой международной службе вращения Земли занимаются! На всё готовы, лишь бы не работать!
  • +20
    Здорово! Можно будет подольше поспать!
    • +8
      "… я из этой секунды всё дерьмище высплю!" отсылка
  • +6
    Благодаря ссылке узнал из подписи, что в Службе вращения Земли оказывается есть подразделение «Центр ориентации Земли». Да, только ради названий там было бы здорово работать. И любопытно, что подобные службы находятся преимущественно во Франции (Палата мер и весов, к примеру), почему так сложилось.
    • +4
      Мне рассказывали про должность «Ученого Хранителя Фазы». Это был очень важный человек. Он отвечал за хранение позолоченного куска эталонного волновода и ему отпускали спирт на его протирку.
  • 0
    Красота. День рождения будет на секунду дольше :)
    • –2
      А моё ждать на секунду дольше.
  • +1
    И всетаки я не понимаю. В серверах же не ставят атомные часы. Так, примерные… Предположим, что часы в моем сервере отстают на 1 секунду каждый месяц. Мне по любому нужно реализовать синхронизацию внутренних часов сервера с UTC. Для этого раз в час, например, я получаю точное время и в какой то момент обнаруживаю что серверные часы показывают 10:00:00, а точное время 10:00:01. И мой софт должен правильно отрабатывать эту ситуацию. И не такая уж она редкая. И легко тестируется, кстати.

    В чем проблемма?

    • 0
      Из комментариев к новости можно сделать вывод, что на сервере время по Unix не меняется две секунды подряд, от этого и проблемы.
      • 0
        от этого и проблемы
        Понятно что от этого. Вопрос то в том, в чём они заключаются?
        • 0
          Думаю, лучше вот так: habrahabr.ru/post/146863/#comment_4960132
          • 0
            Так понятнее, спасибо. Баг в коде, который как раз должен обрабатывать leap second.
  • –1
    Наконец-то, хоть посплю подольше!
  • 0
    А в чем смысл астрономического времени? Почему нельзя пользоваться автономным временем, привязав его к астрономическому событию один раз? Ведь пока эта секунда только мешает жить, а когда она понадобится, будут уже другие проблемы, вроде синхронизации локального времени на разных планетах:).
    • +1
      Потому, что по астрономическому времени мы живем, то есть меняется день и ночь.
      А временные интервалы измеряются атомными часами, которые должны идти очень равномерно.
      Но, поскольку астрономические сутки меняются из-за замедления вращения Земли,
      необходимо его подстраивать под время, измеряемое атомными часами.

      Вот, кстати, таблица, когда были введены дополнительные секунды:

      MJD Date TAI-UTC (s)

      41317.0 1 1 1972 10
      41499.0 1 7 1972 11
      41683.0 1 1 1973 12
      42048.0 1 1 1974 13
      42413.0 1 1 1975 14
      42778.0 1 1 1976 15
      43144.0 1 1 1977 16
      43509.0 1 1 1978 17
      43874.0 1 1 1979 18
      44239.0 1 1 1980 19
      44786.0 1 7 1981 20
      45151.0 1 7 1982 21
      45516.0 1 7 1983 22
      46247.0 1 7 1985 23
      47161.0 1 1 1988 24
      47892.0 1 1 1990 25
      48257.0 1 1 1991 26
      48804.0 1 7 1992 27
      49169.0 1 7 1993 28
      49534.0 1 7 1994 29
      50083.0 1 1 1996 30
      50630.0 1 7 1997 31
      51179.0 1 1 1999 32
      53736.0 1 1 2006 33
      54832.0 1 1 2009 34
      56109.0 1 7 2012 35
      57204.0 1 7 2015 36
  • 0
    Кстати, именно 30 июня Венера и Юпитер на небе соединяться в одну точку. Это редчайшее астрономическое событие.
    • 0
      Насчет одной точки это вы сильно преувеличили.
  • 0
    Сегодня тот самый день!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.