Comments 27
А можно про проблему №2 более подробно?
так чем, говорите, UTC от GMT отличается?…
GMT (UT1) — солнечное, неравномерное, у секунды разная продолжительность, сегодня одна, а завтра другая, в сутках всегда 86400 секунд. UTC — равномерное, продолжительность секунды зафиксирована со всей возможной точностью, отличие от GMT компенсируется скачками (в некоторых сутках 86401 секунд, в некоторых может быть 86399).
Не понял как проходит математически коррекция POSIX времени и когда? Синхронно с UTC и некоторые целые значения являются невозможными, а некоторые (в теории) секунды могут длиться 2 секунды или может быть откат на секунду?
Не SMOS, а CMOS. Не TspMaxDataRetransmissions, а TcpMaxDataRetransmissions. Очепятки…
А что такое Victor Charlie кроме давно известного Viet Cong?
Тоже удивился. Знаю только Lima Charlie (Loud and Clear) в радиообмене часто используется.
Зачем UTCv2? Почему нельзя перейти на 64 бита?
Таки не написано, зачем POSIX-время учитывает (или не учитывает — с какого места посмотреть) високосные секунды? Это гигантские проблемы для серверов, усложнение алгоритма вычисления следующего момента времени (если было особое сообщение от NTP, то в определённый момент не инкрементировать счётчик), а главное — отход от классического определения «количество секунд с 1970-01-01T00:00:00».
Секунда солнечная отличается от секунды физической — интервал времени, равный 9 192 631 770 периодам излучения, соответствующего переходу между двумя сверхтонкими уровнями основного (квантового) состояния атома цезия-133 в покое при 0 К при отсутствии возмущения внешними полями
Я не знаю, что есть солнечная секунда. Я знаю, что вращение Земли замедляется, а значит иногда появляется 23:59:60 (для соответствия UTC положению Земли). А из-за отсутствия этого времени в POSIX-времени (оно соответствует 23:59:59), реальное количество переходов… с 1970-01-01T00:00:00 до текущего момента не соответствует time()*9192631770.
Оно именно не инкрементирует счетчик? Автор мне выше не ответил как процесс происходит.
Затем же, зачем UTC. Чтобы облегчить выполнение операций с интервалами времени для программистов, нет? Берем человеческую дату-время, переводим её в POSIX, добавляем 86400 и сравниваем это значение с текущим, а при равенстве кричим«проспорил!!!» «сутки прошли».
Как я понимаю, POSIX аналог UTC, но просто с другой точкой отсчета. Считает количество секунд прошедшее с 1970-01-01T00:00:00 по бытовым, а не научным меркам. Спустя целое количество суток (количество секунд кратное 86400) после 1970-01-01T00:00:00 всегда должно быть T00:00:00.
Затем же, зачем UTC. Чтобы облегчить выполнение операций с интервалами времени для программистов, нет? Берем человеческую дату-время, переводим её в POSIX, добавляем 86400 и сравниваем это значение с текущим, а при равенстве кричим
Как я понимаю, POSIX аналог UTC, но просто с другой точкой отсчета. Считает количество секунд прошедшее с 1970-01-01T00:00:00 по бытовым, а не научным меркам. Спустя целое количество суток (количество секунд кратное 86400) после 1970-01-01T00:00:00 всегда должно быть T00:00:00.
POSIX-время — это система координат для компьютерных систем, и если не производить синхронизацию с UTC, то вы не сможете точно произвести математические расчеты связанные со временем. В качестве примера можно привести метеорологический прогноз или торгового робота. В этих случаях время играет решающую роль. Процесс синхронизации описан в стандарте протокола NTP, которому не важно с чем синхронизироваться. До изобретения NTP: POSIX и UTC синхронизировали в ручную. Также очень хорошо описана синхронизация с GPS-устройством в этой статье habrahabr.ru/post/171153/ или в этой habrahabr.ru/post/164185/.
Насколько я знаю, точно могу. Просто в алгоритме перевода POSIX в UTC мне нужно будет учитывать високоснгые секунды вручную, а не тупо на 86400 разделить.
Сейчас тупо на 86400 разделить, учитывать надо лишь високосные дни в соответствии с [вероятно (ибо с момента создания высчислительной техники не было различий с Юлианским)] Григорианским календарём. Но это только пока, с замедлением вращения Земли придётся создавать другой календарь, количество високосных дней изменится, так что даже в текущей реализации для расчётов будущих событий необходимо пользоваться UTC (пример: разница в 5 витков вокруг Солнца = +5 лет по UTC, а по POSIX — неизвестно).
Разница в том, что POSIX — число (обычно натуральное, но его можно расширить на действительные), а UTC — строка. В теории оно может поддерживать хоть 23:59:61, когда Земля совсем медленно станет вращаться.
Да хрен с этими вычислениями — можно хоть таблицу создать с опорными точками [сейчас каждые 6 месяцев], в которых будет соответствие между UTC и POSIX.
Да хрен с этими вычислениями — можно хоть таблицу создать с опорными точками [сейчас каждые 6 месяцев], в которых будет соответствие между UTC и POSIX.
Мне кается, что на самом деле «гиганские проблемы» сводятся к тому, что если система замкнута, то у всех её подсистем время должно быть одинаково в рамках данной системы, а расхождение со мировым стандартом можно и пересчитать. Мне в рамках домена Actve Directory без разницы мировое время с точки зрения систем, мне главное чтобы расхождение между серверами и клиентами было меньше 5 минут, иначе дальше клиент просто не получит авторизацию. ну и если произойдёт рассинхронизация между серверами, то проблемы могут начаться на уровне репликации LDAP/SQL баз между серверами AD/SQL, тоже самое касается чтения журналов работы систем — если я знаю разницу между временем сервера и общим временем, пересчитать время события — одна операция. Другое дело что контроллеры AD должны быть синхронизированы с внешним сервером и сервера с клиентами могут иметь разные часовые пояса…
Sign up to leave a comment.
Victor, Charlie, Victor, Charlie, приём