Комментарии 56
Раз уж написали статью на хабр, может обьяснительные ссылки о проблеме хотя бы приведете? Я вот вообще не в теме, но мне очень любопытно.
Это называется leap second, UTC это апроксимация UT1 (которое вычисляется астрономическими рассчетами), поэтому время от времени требуется корректировка.
У нас был такой баг: делали cond_wait (или epoll, не помню точно) с временем ожидания в 1 секунду, он сразу завершался как будто с таймаутом, в итоге 1 ядро процессора съедали на 100%. JVM вообще падала :) Лечились все проблемы перезагрузкой или хитрой манипуляцией с датой-временем на машине.
Мы когда админа на Debian искали, так один из «коварных» вопросов был сколько секунд в минуте. Кстати, не все вспоминали.
Глядишь, после лета 2015-го вопрос опять будет актуальным.
Глядишь, после лета 2015-го вопрос опять будет актуальным.
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 тоже, ну и т.п., больше вендорная задача, т.ч. такие знания в ежедневных применениях нужны достаточно узкому кругу лиц, ну и к тому же развитый человек сможет изучить данный вопрос и сделать выводы, т.ч. в принципе вопрос как профессиональный вообще ничего не стоит, как посмотреть на развитие человека в очень узкой области нормальный.
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 тоже, ну и т.п., больше вендорная задача, т.ч. такие знания в ежедневных применениях нужны достаточно узкому кругу лиц, ну и к тому же развитый человек сможет изучить данный вопрос и сделать выводы, т.ч. в принципе вопрос как профессиональный вообще ничего не стоит, как посмотреть на развитие человека в очень узкой области нормальный.
Таки тоже ни хрена не понял: нам ntp-сервера UTC, которое по time(0) выдаётся, на секунду задержат или просто оно от международного атомного времени будет ещё больше отставать? Если второе, то почему у людей в прошлый раз системы висли?
Я так понимаю npt будет выдавать дубли в эту самую секунду
Первое, первое, читайте Википедию, ищите в инете и т. д. И на идеальной операционной системе, соответствующей всем стандартам, команда date должна в определённый момент выдать 23:59:60, хотя, не факт, что реальный date этим стандартам соответствует
date просто форматирует unix time, который в теории представляет собой целое число секунд, прошедших с полуночи по UTC 1 января 1970г. Оказывается, это не так, поскольку господа координаторы сдвигают время, раз в несколько лет скрывая по секунде, что на мой взгляд абсолютно неверно, потому что реальный интервал между датами/временем будет больше, чем просто разница между переведёнными в time_t. А если нужно отслеживать точные интервалы, придётся обрабатывать такие события, вместо того, чтобы просто учитывать эти секунды при форматировании дат, как учитываются часовые пояса с летним временем и високосными годами.
Насчёт Википедии и поиска в Инете: Хабр всё-таки не просто новостной ресурс, IMHO в статье должны быть хотя бы ссылки на материалы, а главное — нормально рассмотрены последствия для типовых PC и серверов (Windows и Linux).
Поведение NTP-серверов описано здесь. Часы поручиков стоят одну секунду.
Насчёт Википедии и поиска в Инете: Хабр всё-таки не просто новостной ресурс, IMHO в статье должны быть хотя бы ссылки на материалы, а главное — нормально рассмотрены последствия для типовых PC и серверов (Windows и Linux).
Поведение NTP-серверов описано здесь. Часы поручиков стоят одну секунду.
«Международная служба вращения Земли» — классное название.
Ну только с таймзонами разобрались =((
Интересно много ли программ рассчитано на 61 секунду в минуте. Атомные часы таки тоже спешат.
Там таки без разницы — главное, чтобы интервалы стабильные были, а отображение абсолютных значений всегда можно настроить.
А программам-то что? Время синхронизируется сверху, как будто внутренние часы отстали на секунду. Подавляющая часть it-сектора даже не заметит.
Возможно проблемы будут у каких-нибудь распределённых систем.
Возможно проблемы будут у каких-нибудь распределённых систем.
Могут быть проблемы в выводе и форматировании. Например, кто-то хочет в бд записать время в TZ-нотации, пишет 23:59:60, а ему говорят «неверно!» и программа сворачивается в неожиданном месте.
То есть те, кто время считают, вероятнее всего, не заметят. А вот те, кто вводят/выводят данные, могут получить неожиданности. Например (гипотетически) реактор решит, что пора опускать стержни и надо это сделать через минуту. ПО берёт текущую дату, добавляет минуту, и начинает в poll-режиме ждать, когда станет 61 секунда следующей минуты. И ждёт, и ждёт…
То есть те, кто время считают, вероятнее всего, не заметят. А вот те, кто вводят/выводят данные, могут получить неожиданности. Например (гипотетически) реактор решит, что пора опускать стержни и надо это сделать через минуту. ПО берёт текущую дату, добавляет минуту, и начинает в poll-режиме ждать, когда станет 61 секунда следующей минуты. И ждёт, и ждёт…
В смысле, если будет перескок через секунду? То есть так же, как с переводом на час с 2:00 на 3:00, когда например 2:30 просто не будет?
Я спекулирую. Такой 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'
А вот ошибки приведения при таких секундах — суровая реальность.
Собственно, пример бага (python):
>>> time.ctime(time.mktime((2015,06,30, 23, 60, 00, 0, 0, -1)))
'Wed Jul 1 00:00:00 2015'
Обещается же, что будет возвращаться время без этой секунды, будет 59-я секунда в течении двух секунд.
Может стоит за минуту до этого сервера и перегрузить планово… хотя для всех сразу…
Может стоит за минуту до этого сервера и перегрузить планово… хотя для всех сразу…
Считаем скорость чего-нить: измеряем путь пройденный за секунду и делим на разницу времени (23:59:59-23:59:59), ну, а дальше зависит от нашей удачи.
И сколько они уже этих секунд надобавляли?
Пост не читай
@@@
Комментарий пиши
@@@
Комментарий пиши
с 01.07.2012 00 ч UTC до 01.07.2015 00 ч UTC: UTC-TAI = -35 с
с 01.07.2015 00 ч UTC до дальнейшего уведомления: UTC-TAI = -36 с
А где сказано, что это всё и есть добавленные секунды?
Википедия читай . Пока 25сек.
Интересное решение добавить один час через 6000лет.
Интересное решение добавить один час через 6000лет.
del
Здорово! Можно будет подольше поспать!
"… я из этой секунды всё дерьмище высплю!" отсылка
Благодаря ссылке узнал из подписи, что в Службе вращения Земли оказывается есть подразделение «Центр ориентации Земли». Да, только ради названий там было бы здорово работать. И любопытно, что подобные службы находятся преимущественно во Франции (Палата мер и весов, к примеру), почему так сложилось.
Красота. День рождения будет на секунду дольше :)
И всетаки я не понимаю. В серверах же не ставят атомные часы. Так, примерные… Предположим, что часы в моем сервере отстают на 1 секунду каждый месяц. Мне по любому нужно реализовать синхронизацию внутренних часов сервера с UTC. Для этого раз в час, например, я получаю точное время и в какой то момент обнаруживаю что серверные часы показывают 10:00:00, а точное время 10:00:01. И мой софт должен правильно отрабатывать эту ситуацию. И не такая уж она редкая. И легко тестируется, кстати.
В чем проблемма?
В чем проблемма?
Из комментариев к новости можно сделать вывод, что на сервере время по Unix не меняется две секунды подряд, от этого и проблемы.
от этого и проблемыПонятно что от этого. Вопрос то в том, в чём они заключаются?
Думаю, лучше вот так: habrahabr.ru/post/146863/#comment_4960132
Наконец-то, хоть посплю подольше!
А в чем смысл астрономического времени? Почему нельзя пользоваться автономным временем, привязав его к астрономическому событию один раз? Ведь пока эта секунда только мешает жить, а когда она понадобится, будут уже другие проблемы, вроде синхронизации локального времени на разных планетах:).
Потому, что по астрономическому времени мы живем, то есть меняется день и ночь.
А временные интервалы измеряются атомными часами, которые должны идти очень равномерно.
Но, поскольку астрономические сутки меняются из-за замедления вращения Земли,
необходимо его подстраивать под время, измеряемое атомными часами.
Вот, кстати, таблица, когда были введены дополнительные секунды:
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
А временные интервалы измеряются атомными часами, которые должны идти очень равномерно.
Но, поскольку астрономические сутки меняются из-за замедления вращения Земли,
необходимо его подстраивать под время, измеряемое атомными часами.
Вот, кстати, таблица, когда были введены дополнительные секунды:
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
Кстати, именно 30 июня Венера и Юпитер на небе соединяться в одну точку. Это редчайшее астрономическое событие.
Сегодня тот самый день!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
30 июня 2015 г. будет на секунду длиннее