Комментарии 63
Странно, откуда взялась проблема. В годе примерно 31,5 млн секунд. Секунда определена примерно 9 млрд периодами излучения. Разница более 2 порядков. Значит нет проблем так определить секунду, чтобы високосная секунда набегала не раз в год, а раз в век.
В 67-ом году неточно посчитали при назначении секунды?
Вращение Земли вокруг своей оси замедляется, определить секунду так, чтобы високосная секунда набегала раз в век и эта схема действовала хотя бы несколько веков, невозможно.
Сутки как раз меняются очень мало. Около 2 мс за век, насколько помню.
Да, вот откопал https://habr.com/ru/articles/372959/
Это никак не объясняет, почему секунда определена так, что за сутки набегает 2-3 мс погрешности. Вращение Земли даёт такое замедление лишь за век.
+2 лишние миллисекунды в сутках за век это много.
Эти две лишние миллисекунды в сутках по итогам года дадут разницу в 0,73 секунды (0,002 * 365). Вот и получаются ожидаемые 60-70 високосных секунд на протяжении века.
Почему секунда определена так, что прямо сейчас есть погрешность в 2-3 мс за сутки, не знаю. На мой взгляд, это и не важно: даже если переопределить секунду так, что в 21 веке "все будет хорошо", в 22 веке опять возникнут лишние 0,73 секунды за год и это бесконечная история.
А теперь умножьте эти 2-3 мс на 365 и получите эту самую секунду за год.
Значит нет проблем так определить секунду, чтобы високосная секунда набегала не раз в год, а раз в век.
Проблема ведь не в точности определения секунды, а в "неточности" вращения Земли. "Линейка" кривая :).
В 67-ом году неточно посчитали при назначении секунды?
Для 67-го года это было точное значение. Но с тех пор Земля замедлилась.
Переопределять секунду, подстраивая под вращение тоже плохая идея - секунда установлена как одна из опорных констант в системе измерений и если её менять поедут физические константы и значения. Именно поэтому её и зафиксировали с менее стабильного эталона на более стабильный (абсолютный в пределах текущих физических представлений).
Для 67-го года это было точное значение. Но с тех пор Земля замедлилась.
История внесения високосных секунд говорит об обратном. Вначале приходилось добавлять високосную намного чаще, чем в 21 веке.
Возможно, тогда сделали расчёты замедления и выбрали секунду, которая будет средней в ближайший век. Но были ли тогда измерения и прогнозы столь точными...
Непонятно, почему високосная секунда вызывает такие серьезные проблемы, а рутинная синхронизация набортных часов с серверами точного времени проходит без заметных последствий. В чем принципиальная разница?
Все полагают, что секунды находятся в диапазоне 0...59. На самом деле он 0...60 из-за високосных секунд, но поведение софта в таких условиях мало кто проверяет.
Например, формула перевода дней в секунды: seconds = days*24*60*60 - в общем случае не верна, т.к. количество секунд зависит от конкретных дней в календаре. Однако вы этого не заметите, если не занимаетесь обработкой исторических данных, либо пока однажды в будущем часы не скорректируют ещё раз.
В истории так же был казус, связанный с гипотетической ситуацией, когда может добавиться сразу две високосные секунды. Из-за этого максимальным значением для секунд в python принято считать равным 61 https://bugs.python.org/issue2568.
Високосная секунда это просто какое-то торжество техники над здравым смыслом. Видимо авторы стандартов были очень горды, что человечество научилось мерять неравномерность вращения земли и придумали это усложнение.
Уход местного полдня мене чем на минуту за век не будет проблемой ни для кого. В бытовом смысле его не заметят, а у астрономов свой счет времени. А так писатели стандартов написали такой бред что преобразовать дату/время в будущем из HH:MM:SS в одно число - секунды от начала эпохи однозначно невозможно/
Ошибаетесь. В астрономии, например, уход времени даже на несколько секунд означает, что вы опоздаете зафиксировать предсказанное событие. А так да, можно и 29 февраля отменить.
Так пускай астрономы используют своё время, не привязанное к вращению какой то планетки?
Так то человек прав, 24 часовое время - условность. Собственно, как и даты. Учёные давным давно узнали что сутки - это не 24 часа, а год - не 365 дней по 24 часа. И всё равно продолжают жрать кактус, приправляя его переходами на летнее время.
Казалось бы - вот есть конкретная временная точка - 1 января 1970 года. Отсчитывай от неё в любую сторону, с любой необходимой точностью. Но нет, мы будем продолжать страдать, вносить поправки, синхронизироваться непонятно с чем, но не будем менять стандарт.
Вы просто не в курсе. Ачтрономы и используют свое время, называется эфемеридное время. Проблема возникает тогда, когда надо перевести эфемеридное время в обычное, которым на Земле пользуются.
Проблема возникает тогда, когда надо перевести эфемеридное время в обычное, которым на Земле пользуются.
Переводить астрономическое время в гражданское нужно приблизительно только астрономам же? Которые этим и так вроде бы занимаются постоянно. И наличие високосных секунд в гражданском времени только головной боли в эти переводы добавлять должно.
Еще можно с григорианского календаря вернуться на юлианский, он проще. Или вообще високосные года отменить, а то они только головной боли прибавляют. Правда тогда новый год на лето переедет, но это не беда
У арабов он и переезжает постоянно. Причем это не один день в четыре года, а 10-12 дней каждый год. И ничего, никого у них там не парит.
Конечно не парит. Если нет систем точного геопозиционирования, то какая разница, неделя туда, неделя сюда.
А как наличие точного геопозиционирование связано с условным произвольным календарем? Системе геопозиционирования вне зависимости от точности как-то по барабану, новый год сегодня или нет. Все одно, пересчитывать время ко времени клиента с учетом всей этой лабуды с разными длинами месяцев, високосных годов (в арабском календаре они тоже есть, но по другому поводу), летним и поясным временем и прочими непотребствами человеческих календарей и местных особенностей отсчета времени..
Системе геопозиционирования, действительно, по барабану, какой сейчас год, месяц или день, она живет по равномерному времени. Зато вам это не по барабану, потому, что ваша жизнь зависит от смены дня и ночи и времен года. Для того, чтобы ваша полночь не съехала на утро и вводятся високосные секунды.
Для того, чтобы ваша полночь не съехала на утро и вводятся високосные секунды.
И намного съехало бы, если бы не ввели високосную секунду?
Больше чем разница между поясным и астрономическим временем или нет?
Для того, чтобы ваша полночь не съехала на утро и вводятся високосные секунды.
И через сколько веков это произошло бы если "За последние сорок лет набежала разница уже больше половины минуты."?
Ну да, юлианский календарь имеет неточность всего 11 минут. Через сколько веков это заметно будет ?
Ну да, юлианский календарь имеет неточность всего 11 минут. Через сколько веков это заметно будет ?
11 минут за год и примерно 1 секунда за год - разница довольно существенная (в 600+ раз).
В случае обсуждаемой секунды за столетие набежит чуть больше минуты, за тысячелетие 10 минут.
К тому же переход между календарями делался один раз за много веков, а секунда эта вносит суету регулярно.
29 февраля не вносит суету регулярно ? Секунду в год вы даже не заметите, а вот целые сутки каждые 4 года - еще как.
Так високосный год считается по простой формуле, там все полностью предсказуемо и давно учтено в программном обеспечении. Эта же секунда добавляется не каждый год (и не всегда в конце года, бывает в середине) по какой-то своей хитро-вывернутой логике.
Я секунду действительно не замечу, а вот со всякими программными продуктами завязанными на точном времени проблемы быть могут. Потому и вопрос - зачем добавлять то, что человек не заметит, а софту проблемы создает?
Иметь две шкалы времени вместо одной - это упрощение ? У человечества уже один геморрой с существованием юлианского и григорианского календарей уже есть.
Аргумент насчет того, что это удобно софту просто смешной. Это все равно, что сказать - давайте 2038 год считать нулевым потому, что у нас счетчик секунд переполнится. Софт должен подстраиваться под людей, а не наоборот.
Так астрономы именно так и делают
https://core2.gsfc.nasa.gov/time/ - в качестве таймстампа используется юлианская дата
В некоторых местах планеты ещё к метрической системе не перешли в быту, но в науке это основной стандарт. Аналогично можно вводить эфемеридное время для всё более широкого использования. А его даже в стандартных библиотеках яп наверняка нет
В астрономии в расчетах не используют UTC, и часто даже юлианский календарь используют. Так проще. Вообще для любых наблюдений за чем угодно плоское время (просто один счетчик единиц времени) удобней всех вариантов с секундами, часами, днями, месяцами потому что разницв во времени между двумя отсчетами можно вычислить в одну арифметическую операцию.
Вы путаете юлианский календарь и юлианские дни. Это разные вещи.
Год в астрономии (физике) - 365,25 дней ровно, к примеру, световой год именно таков.
Да, в юлианском календаре и юлианских днях, которые используются в астрономии, продолжительность года совпадает. Но это все равно разные вещи.
Да, разные, но генетически связанные, причём совсем не только и не столько прилагательным "юлианский". 😉
Скрывай, не скрывай, а юлианская дата (день) по российским/советским нормативным актам, к примеру, по ГОСТ 8.515-2016:
Началом каждого Юлианского дня считают гринвичский полдень. Юлианская дата — форма записи по шкале времени, ведущей отсчет в сутках от начального момента, соответствующего 12 часам 1 января 4713 г. до новой эры по Юлианскому календарю.
Сравните с её определением в терминах григорианского календаря: "November 24, 4714 BC, in the proleptic Gregorian calendar", есть же разница?
Еще раз - юлианский календарь и отсчет времени по юлианским дням - никак между собой не связанные вещи. И название у них от разных юлиев.
И название им Скалигер дал от одного и того же Юлия, точнее образовал от "Юлианского периода" "Юлианского календаря". Ну и, естественно, одно определяется через другое, изначально.
P.S. Ну, да, забытое: не только Скалигер, но и сам Гершель руку приложил.
P.P.S. Так и да, оказывается сей миф, о происхождении термина "юлианский период" от отца Скалигера - Жуля Сезара Скалигера, встречается. Но сам Скалигер писал иное! Что б не забыть, занёс упоминание этого мифа в Русскую Вкипедию.
Наука прекрасна тема, что в ней можно совершать грандиозные ошибки. За то теперь мы научились четко различать календарное время, которое связано с изменяющимися во времени (sic) величинами: местными традициями, скоростью вращения Земли и решениями глав отдельных государств. И абсолютное (monotonic time), которое не смотря ни на что нас все равно всех объединяет.
по этому надо менять в наносекундах от начала эпохи и пользоваться этим в расчетах, а переводить в человеческие часы-минуты и обратно только при взаимодействии с пользователем.
Хранятся они в одной 32-битной целочисленной переменной, максимальное
значение которой может достигать 2 147 483 647.....
Операционные системы наверняка должным образом адаптируют
да как-бы давно уже все адаптировали.
printf("time_t size in bytes = %ld\n", sizeof(time_t));
выдает time_t size in bytes = 8
Ну понятно что в каком-то роутере где до сих пор 32 битный линукс часы неправильно переведутся или в другом старом железе/ос. Но много ли такого железа доживет до 38 года?
много ли такого железа доживет до 38 года?
Примерно тот же аргумент приводили в 1970 году.
Простите не понял. Хранение даты как двух последних символов года это же чисто софтовое решение. Чтобы его исправить нужно лишь поменять код программы. Хранение даты как системного числа в типе time_t завязано на операционную систему. Это изменить намного сложнее и как правило требует перехода на 64 битный линукс, что требует перехода на 64 процессор. Поэтому в первом случае проблема никак не связана с железом.
Хранение даты как двух последних символов года это же чисто софтовое решение.
По ссылке, я так понимаю, Вы не ходили. Речь вовсе не про "проблему 2000".
Это изменить намного сложнее и как правило требует перехода на 64 битный линукс, что требует перехода на 64 процессор.
Я уже понимаю, что Вы ничего в теме не понимаете. Разрядность чисел, с которыми работает компьютер, точно так же совершенно никак не связана с разрядностью процессора — я вполне могу написать программу для работы с 2048-битными числами для Z80. Поэтому "изменение разрядности [времени]" соверешенно не требует другого процессора — для этого точно так же "нужно лишь поменять код программы".
я вполне могу написать программу для работы с 2048-битными числами для Z80
Но проблема-то в другом. Вам нужно будет переписать половину ядра системы потому что огромное количество системных функций будут ссылаться на системное время, а оно (удивление) будет завязано на системный time_t. Поэтому конечно если у вас какое-то свое приложение вы можете постараться и адаптировать его, но если мы хотим решить проблему целиком то самое простое это перевести все 32 битные линуксы на 64 битные.
По ссылке, я так понимаю, Вы не ходили. Речь вовсе не про "проблему 2000".
Я сходил по ссылке но почему-то решил что говорите о проблеме Y2K.
Вам нужно будет переписать половину ядра системы
Не знаю, половину ли, но для линукса это уже сделано.
Так что достаточно обновить софт, заменять всё 32-битное железо не обязательно.
Почему бы просто на ввести "цезиевое" время, не зависящее от вращения Земли и не требующее таких корректировок? А для отображения привычного нам времени просто хранить массив дат, когда добавлялась високосная секунда.
Непрерывная атомная шкала времени есть, можно покопаться на Хабре. Как минимум она используется в GPS. Но человеку неудобно работать с атомным временем, ему нужно HMS. Високосные секунды и призваны устранить этот недостаток - чтобы полдень оставался полднем.
Но человеку неудобно работать с атомным временем, ему нужно HMS. Високосные секунды и призваны устранить этот недостаток - чтобы полдень оставался полднем.
А Вы можете прочитать не только первое предложение моего комментария, а еще и второе?
чтобы полдень оставался полднем
А у Вас прямо сейчас полдень приходится на полдень?
Вы из тех счастливчиков, у которых поясное время точь в точь совпадает с астрономическим?
У TAI (международное атомное время) с HH:MM:AS проблем нет, но для него нет нормативных актов за часовые пояса.
Практически каждый раз, когда мы добавляем високосную секунду, мы что-то обнаруживаем. Это реально раздражает, поскольку здесь у нас классический случай, когда мы имеем дело с кодом, который никогда не выполнялся, а значит не тестировался пользователями в типичных условиях.
А, ну да, ну да, в преддверии к 2000 году мы с этим сталкивались. Половина, если не 2/3, толком не знали будет он високосным или ли нет. В этом дурацком (если не сказать, богопротивном) григорианском календаре, правила "за раз в 100 лет" и "за раз в 400 лет" не на каждую человеческую жизнь попадают.
Проблемная секунда