dibr: СЯУ: високосная секунда

(Добавить комментарий)

	dimon_w@lj 2012-06-26 04:48 (ссылка)
	Подозреваю, что "забьют, и синхронизируются с чем-нибудь уже потом." (Ответить)

unreal_undead@lj
2012-06-26 04:52 (ссылка)

Поскольку високосные секунды добавляются не по правилам, а отдельными решениями IERS, узнать о них заранее можно только засинхронизировавшись с каким-нибудь сервером. публикующим протоколы собраний - не думаю, что кто-то такое реализовывал, проще синхронизировать время, а у каких-нибудь Главных Атомных Часов руками стрелку придержать ;)

(Ответить)

	tobotras@lj 2012-06-26 04:55 (ссылка)
	В линуксе сто лет тому сделана поддержка високосных секунд в libc, так что покажут 23:59:60. (Ответить) (Ветвь дискуссии)

	dibr@lj 2012-06-26 04:59 (ссылка)
	Вау. Уважаю. Было бы забавно, если бы от вида 23:59:60 и правда рухнуло бы что-нибудь из софта (ну неожиданно же), но "это вряд ли" :-) (Ответить) (Уровень выше) (Ветвь дискуссии)

	tobotras@lj 2012-06-26 05:06 (ссылка)
	А чего софту-то. Его дело звать какие-нибудь gettimeofday да sprintf, а там уж чего libc напишет, то и показать… (Ответить) (Уровень выше) (Ветвь дискуссии)

dibr@lj
2012-06-26 05:12 (ссылка)

Ну мало ли - "OLE, это когда при копировании из paint в word виснет sokrat"(c). Вычтет чего-нибудь из чего-нибудь, получит -1, и удивится. Вон, у израильских истребителей над мёртвым морем зависал автопилот, потому что абсолютная высота полёта оказывалась отрицательной, а "ошибка 2000 года" в bink/+3.0#26 стрельнула только примерно в марте, и приводила к строчкам с "%s" и "%d" в логах и неответам на звонки - а ведь казалось бы, какая связь, и какая разница...

(Ответить) (Уровень выше) (Ветвь дискуссии)

	unreal_undead@lj 2012-06-26 05:21 (ссылка)
	В общем, я бы воздержался от покупок по карточкам в ночь c 30 июня на 1 июля ;) (Ответить) (Уровень выше) (Ветвь дискуссии)

	dibr@lj 2012-06-26 06:13 (ссылка)
	Купить что-нибудь ровно в 23:59:60, а потом оспорить транзакцию :-) (Ответить) (Уровень выше)

ext_229571@lj
2012-06-26 16:15 (ссылка)

Прикладной софт должен работать с unix time, который есть даже в виндах. unix time — это количество секунд, прошедших с начала эпохи, значение, имеющее физический смысл и не зависящее от пользовательского календаря. А вдруг ты сейчас локаль поменяешь и перейдёшь на китайскую неделю в еврейском календаре? Софт всё равно будет вычитать одно количество секунд из другого.

(Ответить) (Уровень выше) (Ветвь дискуссии)

ext_229571@lj
2012-06-26 16:19 (ссылка)

Да, и внутренний таймер, по крайней мере в Linux, работает в Unix Time, соответственно, никто ничего держать не будет, если високосные секунды в формуле преобразования календаря не учтены (а они не учтены), то при последующей синхронизации по NTP текущее значение Unix Time останется прежним, а календарное смещение будет изменено.

С точки зрения пользователя, это будет означать мгновенный перевод часов на секунду назад, при этом значения интервалов времени не изменятся, т.е. в какой-то момент в минуте будет 61 секунда…

См. тж. http://www.meinberg.de/english/info/leap-second.htm

(Ответить) (Уровень выше)

dibr@lj
2012-06-26 16:34 (ссылка)

Ключевое слово - "должен" :-) Должен - не значит "работает именно так": потребности программистов разнообразны (если мне нужно отлавливать каждую пятую минуту каждого чётного часа, вряд ли я буду делать это именно через unixtime), а особенности реализации этих потребностей - ещё разнообразнее.

А если я вдруг перейду на китайский календарь - что-нибудь вполне вероятно грохнется. Собственно, историй вида "перевели время на час вперёд - программа грохнулась, нашли ошибку, исправили, через полгода перевели на час назад - программа опять грохнулась" в интернете можно найти не одну. И то, что софт "должен" работать корректно и без ошибок - не мешает тому, что софт нередко работает криво и с ошибками :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)

ext_229571@lj
2012-06-27 02:01 (ссылка)

Проблемы прикладного софта никто не отменял, конечно. Но в Linux. например, выстрелить себе в ногу довольно тяжело, поскольку сишные функции не дадут тебе работать с чем-то, кроме таймстемпа, и придётся из date вытаскивать текущие даты, а потом ручками их обрабатывать. Геморрой на ровном месте.

(Ответить) (Уровень выше)

	unreal_undead@lj 2012-06-26 05:07 (ссылка)
	А как libc узнаёт, когда надо эти leap second добавлять? (Ответить) (Уровень выше) (Ветвь дискуссии)

	unreal_undead@lj 2012-06-26 05:08 (ссылка)
	PS уже нагуглил, через тот же NTP и оповещают. Однако да, прикладной софт может и не ожидать... (Ответить) (Уровень выше) (Ветвь дискуссии)

	tobotras@lj 2012-06-26 05:11 (ссылка)
	http://dibr.livejournal.com/493454.html?thread=6589582#t6589582 же. (Ответить) (Уровень выше)

	ext_229571@lj 2012-06-26 16:12 (ссылка)
	А прикладной софт и вовсе работает по таймстампам в Unix Time,ему абсолютно наплевать на пользовательский календарь. (Ответить) (Уровень выше) (Ветвь дискуссии)

unreal_undead@lj
2012-06-27 04:26 (ссылка)

Я б за весь прикладной софт не говорил, какая-нибудь проприетарная банковская примочка вполне может иметь тупой код типа if(sec>= 60) что-то-странное-на-всякий-случай-заблокируем-карту

(Ответить) (Уровень выше) (Ветвь дискуссии)

ext_229571@lj
2012-06-27 04:29 (ссылка)

Ну да, прикладной код должен работать по таймстемпам. Хотя, как я писал выше, для работы не по таймстемпам нужны нетривиальные преобразования вручную, проще сделать без них, но есть программисты, которые тупо не понимают концепции таймстемпа и городят собственные преобразования туда-обратно. А если городят, то и секунд у них всегда 60 ;)

(Ответить) (Уровень выше)

sergey_cheban@lj
2012-06-26 05:01 (ссылка)

Ну вообще-то лишние секунды - не новость. Насколько я понимаю, ОС на них обычно забивают, а time_t считается без учёта лишних секунд. Собственно, это и понятно: формула преобразования time_t в календарные дату-время прошита жёстко и навечно, и 23:59:60 в ней не бывает, а на вращение Земли влияет куча не вполне предсказуемых факторов. Поэтому - только синхронизироваться. А для астрономических целей, наверное, приходится учитывать не только лишние секунды, но и всякие приливы-отливы и дрейф материков.

(Ответить) (Ветвь дискуссии)

	nicka_startcev@lj 2012-06-26 07:25 (ссылка)
	В астрономии -- как минимум вики:'уравнение времени'. Там минут до 15 ошибка накапливается. (Ответить) (Уровень выше)

	_frame_@lj 2012-06-26 05:47 (ссылка)
	Касательно винды ставлю на последний вариант. (Ответить) (Ветвь дискуссии)

	dibr@lj 2012-06-26 06:17 (ссылка)
	Надо будет проверить - могли и сделать, "чисто чтобы было". Проверка простая - в полночь запустить в цикле что-то вроде echo %time% >> time.log, и посмотреть как меняется время :-) (Ответить) (Уровень выше)

	primus_kolya@lj 2012-06-26 07:07 (ссылка)
	При Медведеве такого не было. (Ответить) (Ветвь дискуссии)

	dibr@lj 2012-06-26 07:19 (ссылка)
	Было, было. В декабре 2008 :-) (Ответить) (Уровень выше)

azgar@lj
2012-06-26 17:32 (ссылка)

Представляется сценарий, когда какой-нибудь (сервеный?) софт отмеряет промежуток "ровно в одни сутки" и пишет его куда-нибудь в базу. В будущем, охватывая високосный момент.
А потом, уже после этого момента в другом месте отчитывает "ровно одни сутки" назад. И попадает уже в другую секунду.
И всё виснет и косится.
Хотя, настоящие программисты (тм) с большим подозрением относимся к сравнению дат на равенство. Только больше-меньше.

(Ответить)

	belkatvoya@lj 2012-06-27 10:42 (ссылка)
	Ой, как здорово! Я день рождения буду отмечать на одну секунду больше (Ответить)

	ext_229571@lj 2012-07-01 15:27 (ссылка)
	Фааааак. СЯУ, что в POSIX time тоже есть leap seconds. Это совершенно не unix-way. Совершенно. (Ответить) (Ветвь дискуссии)

	dibr@lj 2012-07-02 06:04 (ссылка)
	Когда я слышу "юниксвей", я почему-то упорно вспоминаю RU.OS.CMP FAQ Q44 (http://lurkmore.to/RU.OS.CMP) :-) (Ответить) (Уровень выше)

	barmashonok@lj 2012-07-02 01:23 (ссылка)
	а у меня теперь часы на компьютере на одну секунду спешат. (Ответить)