Unix Time показывает неправильное время?

Аааа! Мы все умрём!!!

Ты хоть читал, что по твоей же ссылке?

Секунда координации добавляется по астрономическим наблюдениям

Т.е. Землю колбасит вот и меняют. Кто сможет установить после конца света, когда все архивы будут уничтожены, как именно колебалась Земля? А unixtime гарантированно тикает безо всяких поправок. Можно будет привязать любое событие с точностью +-секунду.

Ты хоть читал, что по твоей же ссылке?

Да читал

А unixtime гарантированно тикает безо всяких поправок. Можно будет привязать любое событие с точностью +-секунду.

То есть юникс тайм показывает астрономическое время а не реальное? То что в 2016 гугл размазали эту секунду на 20 часов ты называешь «тикает безо всяких поправок»?

точно помню что за последние 10 лет как минимум 1 секунду в линуксе накидывали на какой-то новый год и писали почему. Вы просто не правильный админ, если это не видели.

точно помню что за последние 10 лет как минимум 1 секунду в линуксе накидывали на какой-то новый год и писали почему.

Накидывали каким образом? Кто куда кидал?

Вы просто не правильный админ, если это не видели.

Я не админ.

Только гугл и размазал. Скорее для пиара. ntp предупреждает о секунде, но не вводит её принудительно (окромя того же гугла).

Как это «ntp предупреждает о секунде»? И что админ должен делать получив такое предупреждение? Как это вообще выглядит?

Индикатор коррекции

я другой анонимус, но я ответил бы общеобразовательно. Если сказали, что время подвинут. То двигают во всех системах отчета одинаково. Юникстайм это просто одна из систем отчета и там все тоже двигается согласно другим системам -) Оп, и мы уже в будущем на секунду. Надеюсь вы поняли, что не может одна система дывинуться, а например, юникстам не подвинули. нет повода волноваться -)

Если сказали, что время подвинут. То двигают во всех системах отчета одинаково.

Все верно, только двигают как? Руками. То есть там где должно быть:
23:59:59 -> 23:59:60 -> 00:00:00
на практике получается:
23:59:59 -> 00:00:00 -> 00:00:01 руками переводят на 00:00:00 (грубо говоря)
и таких переводов уже 27 и когда время пишут в формате xx:xx:xx никаких проблем нету но количество секунд с 1970 стало меньше реального.

спс, не знал о такой фиче этого протокола, только что в результате то происходит когда получают предупреждение? Ведь руками же переводят время назад, ну если не критично?

все форматы одинаково подвинули, что дальше

Дальше получается что юникс тайм показывает неправильное количество секунд с 1970 года.

Я как бы не призываю прятаться в бункеры, просто решил подтвердить правильность своих выводов.

Верно. Получается, unix time показывает, сколько секунд прошло бы с 1970, если бы в каждой сутке было ровно по 60*60*24 секунд, что не так. И Вики, собственно, так же пишет:

Unix time (also known as POSIX time or epoch time) is a system for describing a point in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, minus the number of leap seconds that have taken place since then.

Плюс ссылки: 1, 2.

Я правильно понимаю что Unix Time отстает от реального времени на 27 секунд и за 45 лет эту проблему так ни кто и не решил и судя по всему ни кто и не собирается?

Да, именно так. Только Unix здесь ни при чем.

Ну как бы первое января 1970 это начало эпохи юникс и юникс тайм это название способа исчисления времени. Так что юникс тут при всем. Или я не понял о чем ты.

Ну я о том, что абсолютно та же фигня имеет место в любой другой операционной системе. И вообще IT тут играет зависимую роль. Рулит всем всемирная служба координации времени, а IT сообщество вынужденно подстраивается под их причуды.

Нынешняя система с секундами координации с точки зрения IT выглядит, как невероятно уродливый костыль, но те, кто рулит консерваторией не хотят менять статус кво.

Рулит всем всемирная служба координации времени, а IT сообщество вынужденно подстраивается под их причуды.

Это не причуды а объективная физическая реальность. Например ты ни хрена не сделаешь с тем что период вращения земли вокруг солнца не делится на количество дней без остатка. Но високосный год компьютеры умеют считать а посчитать 61-ю секунду не могут.

То есть юникс тайм показывает астрономическое время а не реальное?

Юниктайм показывает физическое время (к чему там сейчас секунда по СИ привязана?). А высокосная секунда добавляется астрономами, вот с ней время астронимическое. Да, и юникстайм показывает правильное врмя для конкретной ЭВМ на которой исполняется код (но это уже астрофизика и в масштабах планеты можно пренебречь).

Это не причуды а объективная физическая реальность. Например ты ни хрена не сделаешь с тем что период вращения земли вокруг солнца не делится на количество дней без остатка. Но високосный год компьютеры умеют считать

Вы сами то поняли, что сказали? Типа 3 года Земля вертится медленнее, чем в 4-й год? Високосность и есть тот самый уродливый костыль.

Ваша крыша сегодня на 34 секунды сьехала относительно гринвичевского времени. Я так понимаю Unix Time не понимает Вашего мозга.

google://libc leap second

В glibc и uclibc это решено на уровне соответствия POSIX стандартам, как с musl - хз, но думай там это тоже реализовали. Складывается ощущение что ты не даже не пробовал погуглить перед тем как писать пост вида «аааа, всё плохо!»

Я правильно понимаю что Unix Time отстает от реального времени на 27 секунд и за 45 лет эту проблему так ни кто и не решил

Секунда unixtime не равна физической секунде. Для меня это было очень неприятным открытием :-/

То есть секунда unixtime — вообще переменной длины.

Юниктайм показывает физическое время

Увы, нет :-/

Проблема лишней секунды до сих пор актуальна и до сих пор крупные игроки тупо останавливают ntp синхронизацию на минуту в которую приходится leap second, чтобы эти ваши луниксы не сломались

Високосность и есть тот самый уродливый костыль.

Как ты предлагаешь считать 365 дней + 6 часов без костылей?

Складывается ощущение что ты не даже не пробовал погуглить перед тем как писать пост вида «аааа, всё плохо!»

Удивительная способность видеть несуществующее, процитируй где я написал что все плохо.

С чего это?

Часы не могут показывать реальное время если их постоянно переводят назад.

Проблема лишней секунды до сих пор актуальна и до сих пор крупные игроки тупо останавливают ntp синхронизацию на минуту в которую приходится leap second, чтобы эти ваши луниксы не сломались

они действительно останавливают на минуту или на неделю, как придется, только непонятно зачем. Если на конкретном сервере стопануть ntpd то потом при старте время все равно откатится на секунду назад. Это ж как свинью по частям резать.

А если стопануть ntp сервис на центральном узле, об который синхрятся сотни-тысячи серверов, то на этих сотнях-тысячах ntpd все равно помнят о секунде координации и добавят ее когда надо.

С чего это?

1. С элементарной логики :) Если взять соответствие unixtime реальному времени и посчитать число секунд между некоторыми датами первого и соответствующими таймстампами второго.

2. С конкретных реализаций. Например:

No commonly used operating system is able to handle a minute with 61 seconds, and trying to special-case the leap second has caused many problems in the past. Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and “smear” the extra second across these twenty hours. For timekeeping purposes, December 31 will seem like any other day.

https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-w...

Вообще:

ровно в полночь по Гринвичу, карета превратится в тыкву^W^W^W, ядро вставит секунду и оповестит об этом всех читателей syslog, типа вот так: Clock: inserting leap second 23:59:60 UTC
Технически в ядре Linux это делается удлинением последней секунды.

В общем, реализаций несколько, но все они имеют секунду переменной длины, а не число физических секунд с 01.01.1970. Т.е. отмерив в любой момент, например, 100 секунд по разнице в unixt timestamp нельзя гарантировать, что это будет 100 физических секунд aka 100×9192631770 периодов излучения, соответствующего переходу между двумя сверхтонкими уровнями основного состояния атома цезия-133. Это может оказаться 99×..., может 101×..., может 100.14×...

См. моё сообщение выше. Unix time фактически привязан к суткам, а не к секундам СИ. Хотя счёт ведёт в секундах (точнее в 86400-х долях сутки).

а ну это какраз о том о чем я и создал тред, просто неправильно тебя понял.

Ну если еще докопаться что такое реальное ремя... Вообще тут все сложно.

Ну если еще докопаться что такое реальное ремя

«Секунда. Представляет собой интервал времени, равный 9 192 631 770 периодам излучения, соответствующего переходу между двумя сверхтонкими уровнями основного состояния атома цезия-133»

:)

Я к тому что время рассинхронизируется даже на очень точных часах, вспомним экперимент с часами на борту реактивного самолета и на поверности Земли. На прикладнм уровне достаточно наносекунд, а их вполне нормально считает практически бытовое оборудование. Это не имеет отношения к вопросу о высокосных секундах (которые добавляют по факту), а так просто — мысли вслух.

Как оно может показывать не правильно если это просто отсчет?

Тут надо ответить на вопрос: а какое время считать правильным? Ответив на него можно отбросить физический смысл времени и просто синхронизироваться с эталонным.

вспомним экперимент с часами на борту реактивного самолета и на поверности Земли

Э... Пока экспериментально только замедление в гравитационном поле Земли по сравнению со спутниками измеряли. Про самолёт не слышал — боюсь, это за пределами современной точности измерений.

На прикладнм уровне достаточно наносекунд, а их вполне нормально считает практически бытовое оборудование

Ага. Вот только unixtime даже в целых секундах не обеспечивает точности :)

Как оно может показывать не правильно если это просто отсчет?

В том-то и дело, что это не просто отсчёт. Длина секунды в unixtime разная и не соответствует физической секунде.

Про самолет я еще в школьном учебнике читал, взяли двое каких-то супер-точных часов, синхронизировали до каких-то очень мелких значений и одни катали сколько на сверхзвуке. Это и есть какбы сейчас основное эксперементальное доказательство того, что на скорости время течет медленнее (это если упрощенно). Пруф вроде даже в википедии был, мне щас не очень удобно искать.

Разные между собой или отличаются от физической секунды?

Пруф вроде даже в википедии был

Не видел :) Боюсь, что это было описание гипотетического, а не реального опыта :)

Разные между собой или отличаются от физической секунды?

И так, и эдак:

Unix Time показывает неправильное время? (комментарий)

Т.е. и длина секунды unixtime может не соответствовать физической секунде, и длины секунд unixtime в разное время разные. И разница в две секунды реального времени может быть в одну секунду разницы между пробразованиями времени в unitime.

Например, между 01.01.2017 00:00:00 UTC и 31.12.2016 23:59:59 UTC две секунды разницы. Потому что было 31.12.2016 23:59:60 UTC

Преобразуем обе величины в unixtime: 1483228800 - 1483228799 = 1

Эксперимент Хафеле — Китинга

Вот оно:

В октябре 1971 года

Моя мама в школу пошла, в первый класс.

Ага, ясно. Убедил :)

Как оно может показывать не правильно если это просто отсчет?

Этот отсчет постоянно поправляют руками.

Тут надо ответить на вопрос: а какое время считать правильным?

Зависит от целей, атомное время это TAI, «астрономическое время» это UT1, а живем мы все по UTC, и тонкость UTC в том что секунды оно считает по TAI но периодически синхронизируется с UT1.

Т.е. и длина секунды unixtime может не соответствовать физической секунде, и длины секунд unixtime в разное время разные.

Странная формулировка, секунда unixtime это обычная секунда атомного времени и если закрыть глаза на проблемы синхронизации времени то они совпадают на 100% проблема в том что это время периодически синхронизируют с UT1, максимум 2 раза в год, в остальное время все четко.

секунда unixtime это обычная секунда атомного времени

Не всегда: www.linux.org.ru/add_comment.jsp?topic=13652025&replyto=13654362