Понятие дополнительной (високосной) секунды (leap second) было введено в 1972 году International Earth Rotation and Reference Systems Service (IERS) для периодического обновления Coordinated Universal Time (UTC) из-за неточности наблюдаемого солнечного времени (UT1) и долгосрочного замедления вращения Земли. Эта периодическая поправка в основном помогает учёным и астрономам, поскольку позволяет им наблюдать за небесными телами, для большинства задач используя UTC. Если бы коррекция UTC отсутствовала, то необходимо было бы внести изменения в старое оборудование и ПО, синхронизируемое для астрономических наблюдений с UTC.
На сегодняшний день с момента введения високосной секунды UTC обновляли 27 раз.
Возможно, високосная секунда была приемлемым решением в 1972 году, когда она удовлетворяла и научное сообщество, и отрасль телекоммуникаций, однако сегодня UTC одинаково мешает и цифровым приложениям, и учёным, которые часто используют вместо него TAI или UT1.
Наша компания Meta* поддерживает стремление отрасли к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27). Добавление новых високосных секунд — это рискованная практика, от которой вреда больше, чем пользы, и мы считаем, что настало время внедрять новые технологии, которые её заменят.
Снежный перевал
Одним из важных факторов, влияющих на неравномерность вращения Земли, является постоянное таяние и затвердевание ледников на вершинах самых высоких гор мира. Это явление можно легко визуализировать, представив вращающуюся фигуристку, поддерживающую свою угловую скорость руками и ладонями. Когда она раздвигает руки, угловая скорость уменьшается, сохраняя импульс фигуристки. Когда она прижимает руки к телу, угловая скорость увеличивается.
До текущего момента добавлялись только положительные високосные секунды. Поначалу для этого просто прибавляли ещё одну секунду, что приводило к необычной временной метке:
23:59:59 -> 23:59:60 -> 00:00:00В лучшем случае, такой скачок времени приводил к сбою программ или даже повреждению данных из-за странных временных меток в хранилище данных.
Поскольку паттерн вращения Земли меняется, с большой вероятностью в будущем мы получим отрицательную високосную секунду. Временная метка будет выглядеть так:
23:59:58 -> 00:00:00Влияние отрицательной високосной секунды в больших масштабах никогда не тестировалось; оно может оказать разрушительный эффект на ПО, зависящее от таймеров или планировщиков.
Как бы то ни было, каждая високосная секунда представляет собой серьёзный источник проблем для людей, обслуживающих аппаратные инфраструктуры.
Размазывание
В последнее время стандартной практикой стало «размазывание» високосной секунды простым замедлением или ускорением часов. Универсальный способ реализации такого способа отсутствует; Meta* размазывает високосную секунду на 17 часов, начиная с 00:00:00 UTC, на основании содержимого пакета данных часовых поясов (tzdata).
Размазывание високосной секунды в Meta*.
Давайте разберём это чуть подробнее.
Мы выбрали интервал в 17 часов в первую очередь потому, что размазывание происходит в Stratum 2, где сотни NTP-серверов выполняют размазывание одновременно. Чтобы разница между ними была допустимой, шаг должен быть минимальным. Если шаг размазывания слишком велик, NTP-клиенты могут посчитать, что некоторые устройства неисправны и исключить их из кворума, что может привести к перебоям в работе.
Момент начала в 00:00:00 UTC тоже не стандартизирован и существует множество возможных вариантов. Например, некоторые компании начинают размазывание в 12:00:00 UTC днём ранее и растягивают его на 24 часа; некоторые начинают за два часа до события, другие начинают прямо в его момент.
Кроме того, существует множество различных алгоритмов размазывания. Есть коррекция високосной секунды ядра, линейное размазывание (когда применяются равные шаги), косинусоидальное и квадратичное (которое использует Meta*). Алгоритмы основаны на разных математических моделях и создают разные графики смещений:
Размазывание високосной секунды ядра при помощи NTPD
Источник показателя перехода для спутниковых систем навигации (т. е. GPS, ГЛОНАСС, Галилео и Бэйдоу) различается. В некоторых случаях он транслируется спутниками за несколько часов до события. В других случаях время распространяется в UTC с уже добавленной високосной секундой. В разных системах навигации значение високосной секунды различается в зависимости от времени запуска системы.
Разница значений високосной секунды между разными спутниковыми системами навигации.
Для всего этого требуется нетривиальная логика преобразований внутри источников времени, в том числе и нашего собственного Time Appliance. Утеря сигнала спутниковой системы в такое важное время может привести к утере показателя перехода и конфликту, что может вызывать перебои в работе.
Также событие перехода распространяется за месяцы до события в пакете tzdata, а для фанатов ntpd — в файле високосной секунды, распространяемом через веб-сайт Internet Engineering Taskforce (IETF). Отсутствие свежей копии файла может привести к пропуску високосной секунды и тоже вызвать перебои в работе.
Как уже говорилось, размазывание — очень важный момент. Если в этом интервале NTP-сервер перезагрузится, то с большой вероятностью на нём будет «старое» или «новое» время, которое распространится на клиентов и приведёт к перебоям в работе.
Из-за такой неопределённости публичные NTP-пулы не выполняют размазывание, иногда для решения этой проблемы передавая клиентам показатель перехода. SNTP-обычно пошагово изменяют значения часов и имеют дело с описанными выше последствиями. Более умные клиенты могут выбрать стандартную стратегию для локального размазывания перехода. В конечном итоге это означает, что крупные игроки наподобие Meta*, выполняющие размазывание в публичных сервисах, не могут присоединиться к публичным пулам.
И даже после перехода ситуация остаётся рискованной. ПО NTP должно постоянно применять смещение относительно используемого им источника времени (спутниковой системы навигации, TAI или атомных часов), а ПО PTP должно распространять в оповещениях так называемый флаг смещения UTC.
Отрицательное влияние високосных секунд
Високосная секунда и создаваемое ею смещение вызывает проблемы во всей отрасли. Один из простейших способов вызвать перебой в работе — внедрить допущение о том, что время всегда движется вперёд. Допустим, у нас есть такой код:
start := time.Now()
// выполняем какие-то действия
spent := time.Now().Sub(start)В некоторых случаях использования
spent мы можем оказаться в ситуации, когда во время события применения високосной секунды значение должно быть отрицательным. Такие допущения приводили ко множеству перебоев в работе, и они описаны во многих статьях.В 2012 году у сайта Reddit происходили серьёзные перебои в работе из-за високосной секунды; сайт был недоступен 30-40 минут. Это произошло, когда смена времени запутала таймер высокого разрешения (hrtimer), вызвав гиперактивность на серверах, приведшую к блокировке ЦП машин.
В 2017 году Cloudflare опубликовала очень подробную статью о влиянии високосной секунды на публичный DNS компании. Первопричиной бага, повлиявшего на её DNS-сервис, стало допущение о том, что время не может двигаться вспять. Код брал значения времени из апстрима и передавал их функции rand.Int63n() языка Go. Функция rand.Int63n() справедливо запаниковала, поскольку аргумент был отрицательным, что привело к отказу DNS-сервера.
Отказ от високосной секунды
Процесс применения високосных секунд вызывал множество проблем в нашей отрасли и продолжает представлять множество угроз. Вся отрасль в целом сталкивается с проблемами, когда дело касается високосной секунды. А поскольку это такое редкое событие, оно каждый раз разрушительным образом влияет на общество. Требования к точности таймеров становятся всё выше во всех отраслях, и високосная секунда вызывает больше проблем, чем создаёт пользы, приводя к беспорядку и перебоям в работе.
Мы, инженеры Meta*, поддерживаем стремление сообщества к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27), которого, как мы считаем, хватит на следующее тысячелетие.
* — признана экстремистской организацией, ее деятельность в России запрещена.
Комментарии (117)
cepera_ang
27.07.2022 18:18-1Отличное начинание. Когда первый раз читал о том, как это всё появилось, продолжается по инерции и какой геморой несёт всем, то становилось грустно, что человечеству нужно так много времени и усилий, чтобы исправить любые, даже очевидно кривые исторические решения.
ermouth
27.07.2022 18:23+2Как и в любом таком «отличном начинании» аккуратно проигнорирован вопрос «а за чей счёт банкет».
Думаю, стоимости активов Цукерберга как раз хватит, чтобы покрыть затраты на это «отличное начинание».
cepera_ang
27.07.2022 18:42+6Покрыть затраты на что? На то, чтобы астрономы перестали сеять периодический аналоговый хаос? Лучше спросите — за чей счёт банкет по проведению всех этих перечисленных работ по обновлению информации об этих лишних секундах.
Зайдите хотя на англовики, там хорошо изложена суть проблемы и то, что проблему обсуждают уже пару десятков лет и есть большое желание убрать вызванные этим неудобства. Эта статья просто ещё один голос в эту сторону.
DrPass
27.07.2022 18:47-2Лучше спросите — за чей счёт банкет по проведению всех этих перечисленных работ по обновлению информации об этих лишних секундах.
А вы правда думаете, что программисты Мета не осилят такую операцию, как сделать скрипт, выполняющий перевод часов на серверах на одну секунду без последствий и для данных, и для бюджета?cepera_ang
27.07.2022 19:11+9Вы не понимаете, это проблема не только Меты. Для всех распределённых систем эти лишние секунды — это разрыв в монотонности времени, скачок типа y2k, только рукодельный. И самое главное — нужный для …. Для чего, кстати? Для тестирования. как будут вести себя системы синхронизированные до микросекунд? Как правильно реализованы таблицы перевода из одних временных шкал в другие во всех системах на планете? Для того, чтобы было для чего обновлять все компьютеры? «Нельзя отказываться от обновлений, а то у тебя даже часы будут идти неправильно».
Вы понимаете, что это работа для кучи людей на планете — сначала подготовка этих обновлений, потом установка, потом борьба с ошибками в системах, которые написаны за годы прошедшие с предыдущей такой секунды. А всё для того, чтобы синхронизировать монотонные и наджные атомные часы с вращением вихляющего неравномерно камушка, чтобы астрономы не пропустили где солнце находится в конкретный момент времени (хотя у них своя шкала для этих целей есть).
DrPass
27.07.2022 19:18+29Вы не понимаете, это проблема не только Меты. Для всех распределённых систем эти лишние секунды — это разрыв в монотонности времени
Так нет же никакой монотонности времени. Время во всех системах исключительно дискретное, а его переводы — штатная операция, постоянно возникающая в различных узлах. В каждом сервере внутреннее время тикает по своим внутренним часикам, которые регулярно отклоняются от общемирового, и регулярно же корректируются синхронизатором, на те же секунды плюс-минус.
Поэтому это вообще не работа, системы в принципе не должны ломаться от подобных корректировок.cepera_ang
27.07.2022 19:46+1Вопросу времени уделяется огромное внимание, потому что в распределённых системах (а все крупные системы — такие) точная синхронизация даёт очень большие плюшки в производительности, поэтому этому вопросу уделяют большое внимание, вплоть до микросекунд (вот и кварц можно моделировать так, что ни о каких секундах убегания речи не будет).
Модель мира «в компьютере время течёт хаотично и полагаться на это вообще нельзя» — имеет место быть, но имеет очень большую «стоимость» как раз из-за того, что непозволяет использовать решения полагающиеся на надежный ход времени.
DrPass
27.07.2022 20:05но имеет очень большую «стоимость» как раз из-за того, что непозволяет использовать решения полагающиеся на надежный ход времени
На практике модели, которые не полагаются на надёжную синхронизацию сотен и тысяч узлов вплоть до миллисекунд, как раз намного дешевле, чем те, которые имеют в архитектуре такие точки отказа.cepera_ang
27.07.2022 20:41Микросекунд, на минуточку!
А если серьезно, то тут бесполезно обсуждать абстрактные системы в вакууме. Зайдите по ссылке на статью, там в интро прекрасно описано откуда берутся такие пожелания к часам в современном мире.
pfffffffffffff
27.07.2022 23:36В алгоритме консенсуса рафт например используется счетчик времени не зависящий от внешних часов
cepera_ang
28.07.2022 07:40+3Алгоритм консенсуса и нужен для того, чтобы создать логические часы, не зависящие от внешних часов. Именно в этом вся загвоздка — системы вынуждены использовать дорогие и медленные алгоритмы консенсуса, там, где можно было бы просто использовать часы.
maeris
27.07.2022 23:39-1Если уж так говорить, у большинства программ (кроме часов в таскбаре) и доступа-то к абсолютному значению времени быть не должно.
ermouth
27.07.2022 21:23+5На то, чтобы астрономы перестали сеять периодический аналоговый хаос
А давайте с политиков начнём, а?
Часовые пояса как попало и зимнее/летнее время вызывают несравненно большие неудобства. Статья на англовики как раз говорит о том, что проблемы в софте были, но в основном решены.
А астрономы – тишайшие учёные, меньше всего от них хаоса.
cepera_ang
27.07.2022 21:38-1Они не решены, они просто 6 лет назад последний раз проявлялись.
Что мешает тишайшим учёным пользоваться своим временем и не навязывать его как «универсальное»? А точнее, отпустить универсальное в свободное плавание. Да, когда-то была ценность в том, чтобы привязывать одно к другому, сейчас больше минусов, чем плюсов, давайте отвяжем:)
ermouth
27.07.2022 23:33+5отпустить универсальное в свободное плавание
Да давно уже отпустили. А то было бы вот так до сих пор:
Tyusha
27.07.2022 18:38+38Не понимаю претензий к астрономам. Это ваша чисто программистская задача, вот и решайте, и не лезьте в геофизику, не мешайте Земле крутиться. Я понимаю, что Meta было бы удобно 256 дней в году. Но увы.
KyHTEP
28.07.2022 04:17-2Не понимаю претензий к программистам. Это ваша чисто геофизическая задача (точность), вот и решайте, и не лезьте к прикладникам, не мешайте людям использовать "бытовое" время (то, что на часах). Я понимаю, что геофизикам удобно вводить коррекцию для времени по их собственному желанию. Но увы.
andy_p
28.07.2022 12:28+4Да, еще можно 29 февраля убрать. А то какие-то непонятные високосные года астрономы придумали.
Sadler
27.07.2022 19:21+3То есть 17 часов будет не 1 млн микросекунд в секунде, а меньше/больше, что тоже неидеально. Если бы мы хотели сделать действительно незаметную перестройку, надо было бы размазывать эту секунду на весь год, тогда количество микросекунд в секунде не изменилось бы. Но не уверен, что возможно сдвинуть отсчёты на такое небольшое значение чисто технически.
victor_1212
27.07.2022 19:37+4> Если бы мы хотели сделать действительно незаметную перестройку, надо было бы размазывать эту секунду на весь год, тогда количество микросекунд в секунде не изменилось бы.
любое размазывание означает неравномерность времени, предположим для людей незаметную, но не для кварцев которых используется миллионы (консервативно), везде где требуется стабильная частота, среди прочего включая радары, как неравномерность времени скажется на их работе, в том числе вычислении координат самолетов и пр. в центрах управления воздушным движением например?
Sadler
27.07.2022 19:41На уровне железа статичный сдвиг сделать и не получится, т.к. он из года в год разный, потому такой вариант обсуждать бесполезно. В любом случае это будет контролироваться софтом, как бы ни было реализовано.
cepera_ang
27.07.2022 19:50+3Можно этот сдвиг просто игнорировать. За сотню лет накопится просто отклонение на минуту положения солнца, которое плавает туда-сюда на 20 минут в год, переключается на летнее/зимнее время и вообще меняется с каждым метром пройденным по Земле.
victor_1212
27.07.2022 19:51именно так Вас и понял, вопрос сколько придется вносить изменения в этот sw, предположим предназначенный для использования с неравномерным временем, и какой интерфейс нужен чтобы об этой непредсказуемой неравномерности sw знал
cepera_ang
27.07.2022 19:48Там везде используют атомное/GPS время и кладут болт на разницу с UT1/UTC. Проблема в том, что те системы варятся в собственном соку, а компьютерные датируют всякие события, которые имеют пользовательский ввод/вывод и как-то так сложилось, что все привыкли общаться/отталкиваться от UTC.
Одним из решений предлагают сделать отдельное компьютерное время, но у этого минус в размножений временных шкал, что ещё больше всех запутает.
victor_1212
27.07.2022 21:44> везде используют атомное/GPS время
правильно, обычно NTP Time Servers используют GPS , но критические системы могут иметь свой независимый источник единого времени, не обязательно GPS, но синхронизированный с общим источником, вопрос в том что если базой всех расчетов сделать неравномерное время вероятно придется много менять в sw,
imho то что мы имеем сейчас с leap seconds, минимальное зло, время течет равномерно, вставлять leap seconds требуется сравнительно редко, т.е поддерживать |ut1-utc|<1sec, это позволяет ut1 заменить на utc для грубых рассчетов координат с точностью несколько сот метров в абсолютной системе, проблема с ut1 в том что оно существенно неравномерно, и вообще требует наблюдений для своего определения
ps
пример NTP Time Server использующего GPS, как требуется RFC 5905 для primary server
cepera_ang
27.07.2022 21:54Для чего поддерживать |ut1-utc|<1sec?
victor_1212
27.07.2022 22:20+2вращение Земли существенно неравномерно, предположим нужны абсолютные координаты точки, для этого требуется ut1 посколько это по сути и есть угол поворота Земли в абсолютных координатах, т.е. Вам надо делать для начала астрономические измерения, как положено для определения ut1, положения звезд могут дать ut1, но предположим Вам надо достаточно грубо, тогда используете прямо utc, учитывая это неравенство, ошибка координат будет не более сотен метров, примерно так,
кстати из статьи не совсем ясно что такое "leap seconds" которые называются високосными, заметим их вставлено 27 с 1972 года, если бы раз в 4 года за 50 лет их было бы 12, а не 27, дело в том что они вставляются когда ошибка накопится, а не в високосные года, т.е. поддерживается |ut1-utc|<1sec
cepera_ang
28.07.2022 07:51+1Простите, но из этого ответа всё равно не понял, почему нужно держать именно разницу между UT1 и UTC в пределах одной секунды. Источники времени UT1 существуют, так же как и обновляемые дельты с атомным и с UTC, можно в любой момент вычислять положение.
victor_1212
28.07.2022 11:30> Источники времени UT1 существуют, так же как и обновляемые дельты с атомным и с UTC, можно в любой момент вычислять положение.
смотрите, источники существуют т.к. сейчас есть служба наблюдения за вращением Земли, чисто измерительная:
" To obtain UT1, you have to look up the value of UT1-UTC for the date concerned in tables published by the International Earth Rotation Service"
Earth Rotation Service в частности необходима для расчета координат GPS с точностью десятков метров (без использования local reference), что делается автоматически наземной службой,
т.е. за Вас как бы делают всю экспериментальную работу связанную с определением неравномерности вращения Земли, но так было далеко не всегда, когда вводились понятия UTC, и UT1, получить точное значение UT1 было труднее, поэтому решили сделать так чтобы в простых случаях навигации можно было использовать UTC вместо UT1, что давало точность определения собственных координат порядка сотен метров, что было совсем неплохо по тем временам, UTC распространялось службой времени по радио и этого было достаточно, с появлением GPS в общем все изменилось, типа нет особой необходимости вообще знать про неравномерность вращения Земли, но если GPS упадет, например в условиях глобального конфликта, придется делать по-старому, вплоть до определения UT1 по наблюдениям, так что старая система пока сохраняется
cepera_ang
28.07.2022 11:38Ну, то есть небольшая частная задача подчиняет себе универсальное время для всех остальных применений, верно? Кажется, что это себя уже изжило и можно отменять :)
UPD: на случай такого конфликта, что UT1 перестанут публиковать, то и UTC никто корректировать не будет и тогда система автоматически станет такой, как предложено.
victor_1212
28.07.2022 13:06+1> небольшая частная задача подчиняет себе универсальное время для всех остальных применений
не совсем, UT1 = the mean solar time, по сути дела называется временем главным образом по историческим причинам, типа как в средние века по солнечным часам на площади в каждом городе было свое солнечное время, сейчас его меряют намного точнее, и слегка осредняют, но физически это просто измеренная и осредненная скорость вращения Земли на данный момент, его точность определения несравненно грубее UTC, т.е атомного времени с поправками 1 сек при необходимости добавляемыми два раза в год (30 июня, 31 декабря), UT1 не подходит для точных расчетов, оно неравномерно и определяется довольно приближенно, UTC это то что надо для расчетов, оно и распространяется через службы времени, вопрос в том надо ли его продолжать координировать, обеспечивая | UT1-UTC|<1sec, imho особых накладных расходов это не вызывает, но позволяет при необходимости использовать UTC вместо UT1,
в случае force majeure определение UT1 вероятно мало пострадает, т.к. делается многими обсерваториями независимо, но возможно станет мало доступным, системы распространения для UT1 нет, тогда как система распространения UTC и внесения коррекций сильно резервирована и технически проста, а вот GPS достаточно уязвима своими наземными центрами связи и обработки информации, которые собственно и делают основную часть работы, так что подстраховывать GPS, сохраняя координацию UTC с UT1, вероятно оправдано
Ra-Jah
28.07.2022 11:32
cepera_ang
28.07.2022 11:38+2Так наоборот же, всё предложение в том, чтобы зафолдить один из стандартов с другим.
vanxant
27.07.2022 19:35+10Помню, в своё время наелся с переводом часов на зимнее/летнее время. Вперёд ещё ок, хотя случались варнинги мониторинга "целый час нет сигнала". А вот назад, когда час времени "два часа утра" происходит два раза подряд, и сам скачок на час назад, добавил боли. Речь даже не столько о БД, а о бизнес-логике и фронте, где юзеру нужно например показывать графики температуры и давления за сутки + события их выхода за разрешённый интервал.
Вот честно, спасибо ДАМу за отмету этого **вна.
А астрономам,@Tyusha, предлагаю подкрутить свой софт и не морочить всей остальной планете голову. У вас в звёздных сутках всё равно меньше 24 часов, так зачем вы жизнь обычным людям портите?
TyVik
27.07.2022 20:29+9Кстати, в Китае всего один часовой пояс. Люди просто привыкли, что на одном конце страны магазины открываются в 8 утра, а в другом в 11. Эти числа всего лишь условности.
RaphZak
28.07.2022 03:13+11В России вообще классно было бы, у кого то магазин открывается в 8 утра, у кого-то в 10 вечера. Зато один часовой пояс.
balamutang
28.07.2022 08:07+7С другой стороны это все условность, ну будет магазин работать с 10 вечера до 6 утра, вопрос привычки только, в реальности это будет обычный световой день. Например в Австралии зима в июне начинается и както они с этим живут вполне себе.
nlinker
28.07.2022 11:14+5Просто надо перестать называть моменты времени 8:00 утром, и 22:00 вечером.
vanxant
28.07.2022 14:27На жд не знаю как сейчас, раньше везде было время по МСК. В т.ч. часы на вокзалах, особенно за Уралом, показывали довольно внезапное время.
Didimus
27.07.2022 21:58+7Причём остановили время в самом неудобном положении. В три утра летом уже светло, зато в восемь вечера уже сумерки.
larasage
28.07.2022 07:27+2PS Даже у альтернативно одаренных татар, которые непременно хотят быть в одном поясе с Москвой, получается так:
Казань - восход — 3:40, заход — 19:58
Набережные Челны - восход — 3:27, заход — 19:44
DaemonGloom
28.07.2022 11:55Тут есть особенность. Восход — время, когда солнце появилось над горизонтом. Но светлеть начинает раньше.
larasage
29.07.2022 12:37Аналогично и с заходом солнца, однако...
А если буквоедствовать, то восход/заход - это момент, когда верхний край солнечного диска пересекает воображаемую линию горизонта. Благодаря атмосферной рефракции фактическая продолжительность светового дня больше астрономической даже на экваторе на 7 минут. В более высоких широтах - профит больше.
fizteh147
28.07.2022 12:18+2Есть мнение, что остановили в точности согласно древнейшим определениям: 12 часов дня - это полдень, а 12 часов ночи - это полночь.
Т.е. если вы хотите, чтобы в 11 вечера еще было светло, то на всю ночь у вас максимум два часа и темнота
по древнему определению должназакончиться в час ночи.Неудобненько как-то получается, да? Такие вот у нас определения.
vanxant
28.07.2022 14:34Ну вообще в МСК географический полдень примерно в 12:30. Могли округлить "вверх", т.е. до UTC+4, но выбрали "вниз", поближе к Европе.
Dolios
28.07.2022 16:22+2Наоборот. В 3 или в 4 утра посветлеет, разницы никакой нет, все равно блэкаут шторы покупать. Темнеет не в 8 вечера, а в 10-11 летом на широте Москвы, зато зимой утром светлеет хотя бы в 9-10, а не в 11, как было после первой попытки.
me21
28.07.2022 09:19+1Вот поэтому в бизнес-логике надо оперировать временем UTC. А в местное время переводить только для показа юзеру. И будет на графике вот тут два часа ночи зимнего времени, а вот тут два часа ночи летнего времени.
vanxant
28.07.2022 14:32+1Ну вот есть месячный отчёт. По вертикали даты, по горизонтали часы, в "таблице", собственно, графики. И тут хоба! В одном из дней 25 часов!
Я не говорю что это невозможно, я говорю, что сутки по 23 и 25 часов немного всё ломают.
Используемые в реальной жизни форматы даты/времени также не подразумевают обозначения зимнее/летнее. Да и в коде, чего уж там, поставить напоминалку через сутки - это
now + 24*3600.Всё это можно как-то обойти, но зачем?
leotsarev
28.07.2022 16:51+1Это неправильно. В бизнес логике надо хранить время вместе с часовым поясом. Особенно это касается всяких расписаний. В реальном мире события планируются не на 9:00 UTC, а на 12:00 MSK. И если MSK сдвинется относительно UTC, то и события сдвинется. Надо просто всегда помнить про часовой пояс и оперировать временем ВМЕСТЕ с часовым поясом…
DrPass
29.07.2022 01:27В бизнес логике надо хранить время вместе с часовым поясом.
Зачем? Мы ведь в общем случае даже не знаем, какой там часовой пояс у события должен быть, это свойство не события, а локации пользователя. Наоборот, правильно хранить время именно в UTC, а часовой пояс хранить в профиле пользователя и применять при отображении события. В этом случае одна и та же онлайн-конференция начнётся в 12:00 в Москве, и в 11:00 в Хельсинки, как и должно быть.leotsarev
29.07.2022 07:20+1Тем не менее все календари (exchange, google calendar) делают именно так, как я сказал.
Простой пример: пусть у нач назначена регулярная встреча в 12:00 каждый день в Лондоне. Она будет летом в 13:00 UTC, в зимой в 12:00 UTC
DrPass
29.07.2022 11:50Простой пример: пусть у нач назначена регулярная встреча в 12:00 каждый день в Лондоне. Она будет летом в 13:00 UTC, в зимой в 12:00 UTC
Неа :) Время встречи, которое хранится в базе данных календаря, не меняется. При смене летнего/зимнего времени меняется как раз часовой пояс в локации, т.е. это преобразование тоже происходит у пользователя. Вы даже сами можете глянуть, если вы в стране, которая переходит на летнее время, у вас при этом часовой пояс в системе тоже меняется.leotsarev
29.07.2022 12:05+1Еще раз. Регулярная встреча назначена на 12:00 ЛОКАЛЬНОГО ВРЕМЕНИ ЛОНДОНА. Потому что именно так пользователи назначают встречи. Самолет улетает через год 29 июля в 12:00 по времени Лондона.
Если вы будете хранить это время в UTC, вы ошибетесь.
leotsarev
29.07.2022 12:06Если вы не верите мне, поверьте Джону Скиту. codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet
leotsarev
29.07.2022 07:30Положим также, что я купил билет на самолёт следующим летом с вылетом из Лондона в 12:00. Если все пойдет так, как сейчас, то это будет 13:00 UTC. Маловероятно, но реально событие, что к следующему лету британское правительство отменит летнее время и будет 12:00 UTC.
Если вы в вашем приложении не сохраните данные о часовом поясе, я опоздаю на самолёт.
nct123
29.07.2022 08:37Лол, можно ещё математиков попросить число Пи подкрутить. А то вот они бессовестные, вся планета не одну тысячу лет мучается...
qvan
27.07.2022 19:46+1Почему не использовать unix time для расчета разности дат? Все равно время в нём хранится и считается. Любое размазывание по суткам или году не решит проблему вместо одного сбойного момента будет множество моментов в неопределенное время (допустим мы каждую миллисекунду снимаем показания физического явления будет множество провалов в показаниях из-за того, что мы отматываем секунду в течение суток). Парадигма «попробуйте ещё раз обновить корзину» - сработает и тут. А тот, кому важна эта секунда, будет использовать постоянно растущую систему времени.
eimrine
27.07.2022 20:18+12В «список заблуждений программистов о времени» придётся добавить ещё один пункт:
- длительность 1 секунды равна 9 192 631 770 периодам излучения Цезия-133
Spaceoddity
27.07.2022 23:24+2Меня вот это всегда удивляло. Настолько невнятное определение...
Что излучает цезий и почему (этот момент постоянно опускают)? Это какой-то радиоактивный распад (выбор элемента к этому как бы подталкивает)? Или это боровская модель атома, когда электрон прыгая по орбитам испускает фотоны? Но с этим переходом атома из одного энергетического состояние в другое, связан же неоконченный философский спор между Бором, Эйнштейном и Гейзенбергом - о глобальном детерминизме окружающего мира...
Вытекает из п.2 - а чем вообще доказана стабильность "излучения цезия-133"? Эмпирически? Вот метр привязан (хотя и через секунду) к фундаментальной постоянной - скорости света. Вообще в физике вроде бы достаточно констант, чтобы только через них выразить современную картину мира. Или именно с секундой какие-то закавыки? Хотя какие там закавыки... Можно же к постоянной Планка было привязаться. Хотя бы так "Секунда - время за которое свет в вакууме проходит расстояние равное N планковских длин". И никакой тебе "неопределенности" с этим цезием-133))
kisaa
28.07.2022 02:37+3Как раз недавно была чудесная статья, почитайте, не пожалеете:
habr.com/ru/post/677064
GubkaBob
27.07.2022 20:49+5Прочитал комментарии, но...
Я правильно понимаю, что главная проблема в отмене этих всех високосных добавок/убавок и прочего - в том что тогда через тыщи лет новый год придется летом справлять?
cepera_ang
27.07.2022 21:02+4Через миллионы…
DrPass
28.07.2022 02:47+1… Но если не предпринять меры сейчас, всего-то тыщ через 30 лет новый год придётся справлять вечером
chnav
27.07.2022 21:50+4Одним из важных факторов, влияющих на неравномерность вращения Земли, является постоянное таяние и затвердевание ледников на вершинах самых высоких гор мира.и далее
До текущего момента добавлялись только положительные високосные секунды.В свой время вникая в leap seconds в GPS, где точность измерения времени влияет НАМНОГО значительнее любого сервера, я узнал, что Земля постоянно замедляется вследствие лунных приливов в земной коре. Потому leap seconds до сих пор (т.е. уже 50 лет с тех пор, как было введено это понятие) положительные т.к. скорость вращения Земли хоть и неравномерно, но только уменьшается. Возможно таяние ледниковых шапок как-то влияет, но всяко меньше Луны.
Spoon56
29.07.2022 11:15Луна, конечно, имеет решающее значение в замедлении вращения земли, но только на большом интервале времени. Луна замедляет землю всего на 2 миллисекунды за столетие. Такие резкие изменения скорости, как сейчас, связаны с геологическими и климатическими факторами. И основным фактором на данным момент являются полярные ледники. Вода на экваторе обладает значительным моментом инерции, так как его линейная скорость 450 м/с, а расстояние до оси вращения 6 000 км. При переносе на полярную шапку линейная скорость и расстояние до оси вращения падает, и момент импульса практически полностью гасится. Ему просто некуда деваться кроме как в увеличение скорости вращения планеты. Сейчас у нас идёт обратный процесс, лёд тает, и медленная вода, утекая в сторону экватора тормозит землю. Когда весь лед полностью растает, leap second больше не понадобится.
chnav
30.07.2022 08:32Луна замедляет землю всего на 2 миллисекунды за столетие
Всё верно, с 1820 года КАЖДЫЕ СУТКИ удлинились на 2.5 мсек.
"At the time of the dinosaurs, Earth completed one rotation in about 23 hours," Daniel MacMillan, of NASA’s Goddard Space Flight Center in Greenbelt, Md., said in a statement. "In the year 1820, a rotation took exactly 24 hours, or 86,400 standard seconds. Since 1820, the mean solar day has increased by about 2.5 milliseconds."
It's happening because of tidal forces between the Earth and moon. This mutual gravitational jostling results in the transfer of our planet's rotational momentum to the moon, pushing it away from us at about 1.6 inches (4 centimeters) per year.
Т.е. из-за приливных явлений в земной коре вращение Земли замедляется, а Луна отдаляется. Можно посчитать, какова была длительность каждых суток c 1972 по 2022 и просуммировать накопленную разницу.
Таяние ледников это сезонные/декадные флуктуации. В 1820 году никто и не помышлял о глобальном потеплении.
На этом предлагаю закончить. Всё-равно никто кроме нас двоих не читает, а для меня инженеры NASA достаточно авторитетны, чтобы спорить с ними.
shornikov
27.07.2022 21:59+7Если так хочется изменить время - давайте вообще уйдем от 24/60. Введем новую единицу котопая хорошо делится на солнечный год на земле и ближайших планетах, типа марса.
И пусть себе новое время тикает не привязанное к рассвету. То, что солнце встает в 5 утра это ведь догма. Два поколения людей потерпят,а новые люди только в книжках прочитают.
vassabi
27.07.2022 22:20вот вы смеетесь, а на марсе используется своя система измерений дней
так что не стоит преуменьшать потребность в общей системе измерения времени в Солнечной системе :)
KvanTTT
27.07.2022 23:07+1Скорей её мега величина которая будет хорошо делиться на год (в земном году более 31М секунд). Вообще можно взять просто обычную секунду, для которой есть абсолютное определение, и на её основе построить остальные необходимые величины: кило, мега и т.д.
Xobotun
27.07.2022 23:57Пытались уже в конце 18 века, но уже было слишком много привычных циферблатов: десятичное время.
fransua
27.07.2022 22:20+2Кажется, что лучше стоит перестать использовать UTC для чего-то кроме отображения даты пользователю: меток синхронизации, монотонных счетчиков, идентификаторов, таймеров, распределенных БД.
А то получается несколько функций, а значит источников требований, а значит в какой-то момент они начнут противоречить друг другу.
Только тогда придется дублировать всю инфраструктуру вроде серверов NTP, что наверное недешево.
А еще бы разобрались, чем отличается 0:00p.m., 0:00a.m., 12:00p.m. и 12:00a.m. и кто из них кто.
vassabi
27.07.2022 22:23(читаю список багов в программах, которые неправильно работают со временем и список костылей, чтобы замаскировать перевод часов [от лигаси систем, не иначе])
хмм.. странно еще что они не предложили Землю сделать квадратной - чтобы дороги было удобнее строить ...
KvanTTT
27.07.2022 23:12+1Тогда уж плоской. Кстати, земля плоская для архитекторов - её сферическая форма не учитывается при проектировании.
don_ikar
28.07.2022 13:12Насвкидку не могу найти данных, но смутно вспоминаю, что при проектировании больших мостов как раз таки учитывается сферическая форма Земли (а именно - тот факт, что опоры не будут строго параллельны друг другу).
Azraeldk
27.07.2022 23:18+7С учетом того насколько много багов в ПО самой Меты и какая у Меты политика, наряду с тем как вольно Мета распоряжается правами людей, то вполне возможно, что если изложенные в статье тезисы и благие, то это с большой вероятностью может оказаться дорога как минимум не туда, а, если говорить прямо, то в еще больший ад.
Andreyika
28.07.2022 06:24+5Первопричиной бага, повлиявшего на её DNS-сервис, стало допущение о том, что время не может двигаться вспять. Код брал значения времени из апстрима и передавал их функции rand.Int63n() языка Go. Функция rand.Int63n() справедливо запаниковала, поскольку аргумент был отрицательным, что привело к отказу DNS-сервера.
Вроде бы существует такая штука NTP, которая вроде бы как должна корректировать время.
Значит существуют ситуации, когда время внезапно нуждается в корректировке (убежало вперед или назад) и значит будут ситуации, когда убежавшую секунду вернут обратно и получится отрицательная разница и мы вернемся к той же проблеме, но без каких-то "високосных секунд".
Или на включенных серверах корректировать время не принято?
blind_oracle
28.07.2022 14:46Его не корректируют обычно, а замедляют или ускоряют чтобы соответствовать эталону.
Stas911
28.07.2022 06:59+2Тю, секунда, вот неженки-то. В арабских странах бывают целые нерабочие непредсказуемые праздники и ничего, справляются во всех своих системах.
cepera_ang
28.07.2022 08:06+9Интересно, что многие в комментариях сходу встали на защиту существующей системы с аргументами вроде «а вот не надо баги делать», «а вот бывает ещё хуже», «а посмотрите на арабов» и «что сделано, то сделано, не нужно пытаться ничего изменить». Это из-за того, что предложение от фейсбука?
Есть интересный метод, чтобы оценить стоит ли делать изменение, без учёта исторического багажа. Представьте, если бы тогда, в 1972 году, победили аргументы оставить UTC монотонным и привязать его к атомному времени, а не пытаться привязать к вращению планеты. Тогда сейчас было бы две универсальных временных шкалы: UTC/TAI и UT1, которые бы постепенно расходились и разница была бы всегда известна, вместо трёх: TAI, которая идёт монотонно, UT1, которая постепенно уходит и UTC, которая идёт с атомом, но периодически прыгает. Не было бы багов связанных с прыжками времени (от этой конкретной причины), не было бы кода растягивания лишних секунд, не было бы проблем с подсчётом сколько прошло времени между разными событиями. Не было бы работы по обновлению базы с этими секундами и распространению её для всех. И т.д.
И вот в этом гипотетическом 2022 году пришёл бы кто-нибудь и написал статью: «А давайте создадим високосные секунды!» и расписал бы как круто было бы, чтобы UTC периодически прыгала, чтобы была работа по обновлению, чтобы нужно было убеждаться, что всё работает (и что-то всё равно бы ломалось). А плюсы… ну… положение солнца… астрономы…
vassabi
30.07.2022 02:36-1то есть целый високосный день не нарушает плавного течения времени, а одна секунда - "ой всё", сервера падают, у кластеров катастрофа, ужас-ужас
время монотонное в любой шкале, но в минутах не всегда 60 секунд. Вот почему-то вас не удивляет, что хотя дни в году - монотонные, однако в месяцах не по 30 дней ? А в феврале - не всегда 29 дней. И как-то кластеры переживают это из месяца в месяц, не падают в полночь 1го числа следующего месяца ... Может дело все-таки в софте, а не во времени ?
mikhanoid
28.07.2022 09:30Ну, а чё? Вполне укладывается в стратегию по переходу всех в метавселенные: если реальность противоречит виртуальности - тем хуже для реальности. Цифровизация она такая. Гегель одобряет.
IGR2014
28.07.2022 12:03[SARCASM]
Эхх, а можно-то всего поставить на экваторе парочку-другую реактивных двигателей и подкручивать планетку иногда)))
RusikR2D2
28.07.2022 12:55А почему не сделать некое "глобальное" время, никак не привязанное к вращению планеты? И использовать его в качестве эталона для компьютерного оборудования.
А для людей в какие-то даты несколько раз в год поправку для локальных часов (которые для восприятия человеком).
Тогда, кстати, можно избежать резкого перевода времени на летнее-зимнее, а просто размазать этот переход, переводя часы, скажем, раз в месяц или раз в неделю при синхронизации.
Понятно, что раньше с таким были бы сложности, т.к. все часы пришлось бы переводить вручную. Но сейчас большинство часов синхронизируются через интернет.
HOMPAIN
28.07.2022 16:56Вот если бы кто-нибудь начал с милями и фунтами бороться, без них мир точно стал бы лучше.
cepera_ang
28.07.2022 17:18А ещё с курсом валют. Вот удивительное дело — человечество за последние сто лет стандартизировало всё, что только возможно, меры весов, единицы измерения, течение времени, разъёмы, интерфейсы, госты и т.д., но при этом умудрилось соскочить с единого эталона денег в пользу плавающих от балды курсов валют.
Если раньше проблема была в том, что плывёшь из одной страны в другу, а там футы отличаются, но они хотя бы стабильно отличаются и можно по таблицам пересчитать, зато слиток золота был слитком золота и величины не плавали относительно друг друга. То сейчас у тебя тонна — это тонна, метр — это метр, зато курс валют может поменяться, пока твой контейнер с холодильниками ехал через океан и теперь станет выгодно отправить его обратно, а не продавать здесь.
victor_1212
28.07.2022 18:17> человечество за последние сто лет стандартизировало всё, что только возможно
стандартизовать вероятно можно только то что имеет четкие характеристики, например физические, или формальные, информационные (типа кодировка), курс валюты этими качествами не обладает, пока было возможно его привязывали к золоту, но сейчас бумажных денег столько напечатано, что в разы превышает количество всех золотых запасов, так что единственное что возможно это плавающий курс спрос-предложение, впрочем даже этот баланс не так просто поддерживать
cepera_ang
28.07.2022 18:44Это долгий и философский разговор, к которому я наверное не готов сейчас. Но в общих чертах: курсы валют — это придуманная абстракция, такая же как и остальные стандарты и человечеству в целом пошло бы на пользу пошло существование единого эталона (стандарта) ценности (денег). То, что это не выгодно каждому суверенному политическому образованию в отдельности, делает эту проблему плохо разрешимой.
Это просто интересное наблюдение, что мы классно объединились в одних важных аспектах за 20-й век и замечательно фрагментировали другой важный аспект. О чем я не задумывался, пока сегодня не поразмыслил над этими вопросами времени и прочими единицами СИ и разными вопросами метрологии.
victor_1212
28.07.2022 20:19> курсы валют — это придуманная абстракция
согласен, деньги как таковые, или более широко монетарные инструменты, которые по объему и разнообразию превосходят во много раз любые валюты
DrPass
29.07.2022 01:34Но в общих чертах: курсы валют — это придуманная абстракция, такая же как и остальные стандарты
Это сущности разного порядка. Метрические стандарты — это меры. Курсы валют — значения измерений. Градус-то определён в системе Си, но у вас температура может быть 36.6 (не придирайтесь, что не в кельвинах), а может быть 37.2, а может быть 25. Так же и курсы валют, это один из множества экономических индикаторов, и его «измерения» во времени меняются.cepera_ang
29.07.2022 08:15Курс валюты — значение измерений, мера — ценность. Ценность сделанного мной (и другими) для экономики планеты за последний год не изменилась, а измеренная «температура» почему-то то зашкаливала, то показывает трупа. Причём на интервалах в единицы дней.
DrPass
29.07.2022 11:57Ценность сделанного мной (и другими) для экономики планеты за последний год не изменилась
Ценность сделанного вами как раз меняется постоянно в зависимости от того, сколько где чего производится, потребляется, пишется и воруется. Ценность яблока, если оно у вас одно, многократно выше, чем такого же яблока, если у вас их полный погреб. И так устроено всё в экономике.
KvanTTT
28.07.2022 18:54Такое возможно только если все государства объединятся в одно. Даже если такое событие когда-нибудь произойдет, то точно не в наши времена.
mikhanoid
28.07.2022 21:16Простите, но как Вы без плавающих курсов валют будете перераспределять богатства в пользу метрополий?
cepera_ang
28.07.2022 21:21+2Надо признать, до этого момента меня никто не спрашивал, как я буду распределять богатства в пользу метрополий, поэтому я не успел продумать этот вопрос.
izogfif
А звездочки и сообщения о том, что что-то там экстремистское в РФ не нужно разве?
PatientZero Автор
Ага, спасибо, дополнил.
StjarnornasFred
Представляю себе заголовок: "Экстремистская организация, запрещённая в России, посягнула на само время!"
maeris
Панчлайн получился великолепный, спасибо.