Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 153
Затем же что и 29 февраля в високосные года.
Как зачем? Поспать подольше!
29 февраля появляется потому, что один оборот вокруг солнца совершается не за календарный год, а на четверть суток быстрее.
Скорость вращения земли постепенно уменьшается, плюс оборот вокруг оси планета делает не за 24 часа. Следствием этого является добавление «секунд синхронизации», которые можно как добавлять, так и отнимать.
Скорость вращения земли постепенно уменьшается, плюс оборот вокруг оси планета делает не за 24 часа. Следствием этого является добавление «секунд синхронизации», которые можно как добавлять, так и отнимать.
Если вникать полностью, то там ещё сложнее всё: учитываются вещи от квазаров до переходов «между двумя сверхтонкими уровнями основного состояния атома цезия-133». Собственно для «синхронизации» квазаров и цезия-133 и вводится эта дополнительная секунда.
>> Скорость вращения земли постепенно уменьшается
Это еще почему?
Это еще почему?
Сила натяжения пружины ослабевает, а заводить некому
Из-за приливного трения (wiki)
Вообще официально корректирующая секунда введена для компенсации нестабильности вращения Земли, но по факту её только добавляли, вычитать ни разу не пришлось, то есть нестабильность имеет однозначный тренд.
Интересно, почему бы не подкорректировать календарный год и сутки. Ведь точка отсчета то именно оборот.
Потому что добавлять секунду дискретно проще, чем ее размазывать равномерно по всему будущему. Кроме того, добавление этой секунды происходит не раз в сколько-то лет, как 29 февраля, а все чаще и чаще.
Ну проще — да, но это костыль. Ведь, если подумать, что такое год? Время обращения Земли вокруг Солнца. Аналогично, сутки — время обращения вокруг оси.
Когда-то ошиблись при вычислении длительности года — получаем высокосные года, вместо того, чтобы удлинить немного все единицы измерения и пересчитать то, что от этого зависит (сейчас, конечно, это уже сделать очнеь сложно. Но когда-то можно было). Аналогично, слегка уменьшить сутки, чтобы не добавлять по секунде каждый год.
Когда-то ошиблись при вычислении длительности года — получаем высокосные года, вместо того, чтобы удлинить немного все единицы измерения и пересчитать то, что от этого зависит (сейчас, конечно, это уже сделать очнеь сложно. Но когда-то можно было). Аналогично, слегка уменьшить сутки, чтобы не добавлять по секунде каждый год.
Когда-то ошиблись при вычислении длительности года — получаем высокосные года
Просто астрономический год на астрономические сутки нацело не делится, и високосный день 29-го февраля ввели именно для компенсация этого факта, чтобы не сдвигались времена года, (и то нынешняя схема всё равно с ошибкой). А «високосная секунда» по определению не стабильна, без неё пришлось бы корректировать длительность секунды постоянно.
Просто астрономический год на астрономические сутки нацело не делится, и високосный день 29-го февраля ввели именно для компенсация этого факта, чтобы не сдвигались времена года, (и то нынешняя схема всё равно с ошибкой). А «високосная секунда» по определению не стабильна, без неё пришлось бы корректировать длительность секунды постоянно.
Наполеон хотел ввести десятичное время. 10 часов в сутках, 100 минут и 100 секунд. Но, к сожалению, идея не нашла поддержки.
и мы по традиции ползуемся древней 60-ричной системой исчисления
как минимум ещё одна идея у него не получилась :)
Скорее к счастью.
Слегка уменьшить сутки нельзя. Иначе через 2 года в 14:00 будет ночь:)
А вы почитайте про разницу между тропическим годом и сидерическим периодом — узнайте для себя много нового.
Уже нет. Сейчас точка отсчёта период перехода между двумя сверхтонкими уровнями основного состояния атома цезия-133. Макромир менее точен чем микро.
Полагаю, что есть некий кэефициент, который связывает секунды, минут, года и время перехода. Вот его можно покрутить немного.
*коэффициент
И действительно
система единиц СИ определяет одну секунду как 9 192 631 770 периодов. Вот это число можно поправить немного.
система единиц СИ определяет одну секунду как 9 192 631 770 периодов. Вот это число можно поправить немного.
Потомучто Вам придется покупать новые часы после очередного такого «размазывания».
1. Слишком сложно с точки зрения повседневности — представляете, каково перевести мир на новый календарь в компьютерную эпоху?
2. Високосная секунда случается не из-за неточности года, а нестабильности вращения Земли — мало ли, метеориты в этом году много попадали «против шерсти». Ну, очень грубо говоря.
2. Високосная секунда случается не из-за неточности года, а нестабильности вращения Земли — мало ли, метеориты в этом году много попадали «против шерсти». Ну, очень грубо говоря.
В чисто компьютерную как раз проще — прошивки и прочий софт поменять :) Это не в механических часах шестёренки менять.
god@universe:~$ sudo planets --planet earth --rotation_speed 1
[sudo] password for god: ******
god@universe:~$ successfully changed
В пароле 7 цифр. Он за 7 дней создал Землю.
А что делает команда successfully?
чего это god должен sudo-то делать?
Ну кто-то же должен вращать Землю.
Там белые медведи трутся о земную ось…
Зато как звучит! Я бы только ради названия к ним устроился.
— Чем ты работаешь?
— Оператором в Международной службе вращения Земли, #$%#!
— Чем ты работаешь?
— Оператором в Международной службе вращения Земли, #$%#!
Международная служба вращения Земли уведомляет, что с 25 июня 2012 по 28 июня 2012 включительно вращение Земли будет приостановлено для профилактики ядра.
Служба приносит свои извинения за возможные неудобства.
Служба приносит свои извинения за возможные неудобства.
30.06.2012 23 ч 59 мин 59 с
30.06.2012 23 ч 59 мин 60 с
01.07.2012 00 ч 00 мин 00 с
Точно не сказали? :)
30.06.2012 23 ч 59 мин 60 с
01.07.2012 00 ч 00 мин 00 с
Точно не сказали? :)
Живем на секунду дольше, парни, значит — стрелку назад!
На современных цифровых устройствах — никуда :) Время само синхронизируется (ну или самому нужно это сделать), у меня даже на роутере такое есть.
А какая частота добавление таких секунд? Раз в год? Раз в сто лет?
а это как-то учитывается в TIMESTAMP — Date?
Если это про unixtime, то никак, конечно. Как Вы себе представляете оно там должно учитываться? :)
Видимо перевод из unixtime в другие форматы имеется в виду
Последние строки неверные. Ладно бог с ней со второй — особый случай, но третья уже точно неверная.
$ date --date='@1341100799' --utc
Сб. июня 30 23:59:59 UTC 2012
$ date --date='@1341100800' --utc
Вс. июля 1 00:00:00 UTC 2012
$ date --date='@1341100801' --utc
Вс. июля 1 00:00:01 UTC 2012Последние строки неверные. Ладно бог с ней со второй — особый случай, но третья уже точно неверная.
Да почему неверные то? А как должно быть, по-вашему? Как раз тут всё корректно.
Т.е. разница между датами «Пт. июня 1 00:00:00 UTC 2012» и «Вс. июля 1 00:00:00 UTC 2012», выраженных в unixtime должна составлять не 30*24*60*60, а 30*24*60*60+1? :)
Т.е. разница между датами «Пт. июня 1 00:00:00 UTC 2012» и «Вс. июля 1 00:00:00 UTC 2012», выраженных в unixtime должна составлять не 30*24*60*60, а 30*24*60*60+1? :)
Именно. Вас же не удивляет что между 01.02.2012 0:00:00 и 01.03.2012 0:00:00 29*24*60*60, а не 28*24*60*60 как межу 01.02.2011 0:00:00 и 01.03.2011. Или удивляет? :)
Ну нет же, как раз не именно! :) Этого в unixtime не может быть принципиально. Високосный год — пример неподходящий — високосные дни заранее распланированы и, понятное дело, учитываются, ибо это дело календарной важности. А leap seconds не учитываются по определению и в unixtime день всегда 86400 секунд длится.
В unixtime вообще не может быть минут, часов, дней и лет. Там только секунды. Но и эти секунды дело «календарной важности», чтобы в один прекрасный день у нас в полночь Солнце в зените не стояло. И эту секунду заранее запланировали — аж за две с лишним недели :)
Как раз дело в том, что unixtime тупо не предназначен для точных расчётов времени. Это просто представление UTC относительного определённой временной метки, расположенной в прошлом (тоже в UTC в 1970 году). Используется для удобной конвертации между таймзонами и удобного представления. Соответственно, он и не применяется в явном виде во всяких GPS, NTP и т.п., там своя синхронизация по всяким TAI, напрямую относительно UT1 итд итп.
В любом случае leap seconds не учитываются (и не могут просто физически) в unixtime, это факт. Зачем же спорить с очевидным :)
В любом случае leap seconds не учитываются (и не могут просто физически) в unixtime, это факт. Зачем же спорить с очевидным :)
Я говорю о переводе unixtime в UTC («перевод из unixtime в другие форматы имеется в виду») — как тут можно не учитывать, что по UTC сутки 30 июня 2012 года состоят из 86 401 секунды?
Если говорить именно о переводе времени из unixtime в «удобочитаемый вид» в UTC, то да. Вроде, понял что имеете ввиду. Просто смутило — речь пошла о том, что вроде как в unixtime вдруг день окажется 86401 секунды. Реально же, ну что поделать — для 1341100799 покажет 23:59:59, для 1341100800 — 23:59:60 и для 1341100800 ещё раз 00:00:00 и всё пойдёт своим чередом. Да, мы будем знать что реально когда-то именно этот день был дольше на 1 секунду, но это всё — более НИГДЕ реально вы этого никогда не увидите. Ни в компьютерных программах, ни в календарях, нигде. При операциях над unixtime вычитаниях итд итп, вы всегда получите разницу нормальную, как будто не было никакой секунды. О этом и речь, что оно не учитывается нигде. И календарность не сломается. Эта секунда прибавится к уже набежавшим за последние десятилетия десяткам таких секунд и будет использоваться в других местах, и довольно активно.
Почему-то мне кажется, что leap seconds вообще никак не влияют на Unit Time. И не будет дважды подряд 1341100800
Просто при какой-нибудь очередной синхронизации после 1 июля компьютеры обнаружат, что их часы ушли вперед на секунду. И скомпенсируют ее. И какое-то время (не 1341100800, а более позднее) повторится дважды — при условии, что часы компьютера идут идеально.
Ну да, не влияют, если правильно понял фразу, то это то о чём я и пытаюсь сказать выше и ниже. Но всё же «виртуально» будет как будто бы дважды подряд именно в это время. «Реально» же это будет так только в тех местах, где это вообще будет заметно. То есть те, кто знает про это, тикнет именно таким образом. А те, кто не знает — ничего не заметит, всё верно сказали — синхронизируют эту секунду потом (это же и по ссылке на ntp.org ниже написано). В любом случае перевод unixtime -> «настоящее время» останется как был и эти секунды там никогда не проявятся. Для 1341100800 прямое однозначное соответствие будет 00:00:00 и всё.
Почитайте про tz database
Да блин, вы тупо википедию откройте: en.wikipedia.org/wiki/Unix_time
Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since midnight Coordinated Universal Time (UTC), January 1, 1970, not counting leap seconds
Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since midnight Coordinated Universal Time (UTC), January 1, 1970, not counting leap seconds
Иначе бы такие фокусы никогда не работали, а секунды плавали :)
1341100800 -> Sun Jul 01 00:00:00 UTC 2012
1341100800-9999*24*60*60 -> Thu Feb 14 00:00:00 UTC 1985
А кто сказал, что они должны проходить? Может ещё должны проходить
1341100800 -> Jul 01 00:00:00 UTC 2012
1341100800-10*365*24*60*60 -> Jul 01 00:00:00 UTC 2010упс, последнее число 2002
Хм, командная строка сказала, что должны проходить. Сейчас накидал программку на java — она тоже сказала, что должны проходить. А что, не проходит что ли? Я привёл реальные пары unixtime -> время в UTC (не реальное «настоящее» время в UTC, для которого и делается эта поправка, а именно его представление этому значению unixtime, т.е. то что вы всегда получите в компе).
Ваш пример не будет проходить, конечно. Реально там было три високосных года, потому на три дня и сместится вперёд (на 4 июля). А секунды то останутся нулевыми.
Ваш пример не будет проходить, конечно. Реально там было три високосных года, потому на три дня и сместится вперёд (на 4 июля). А секунды то останутся нулевыми.
30 июня 97-го была добавлена 1 секунда.
$ date --date='@867715199' --utc
Пнд Июн 30 23:59:59 UTC 1997
$ date --date='@867715200' --utc
Втр Июл 1 00:00:00 UTC 1997
$ date --date='@867715201' --utc
Втр Июл 1 00:00:01 UTC 1997
Та же самая картина. Т.е. получается, что не учитывается.
Вообще, заметьте, что unixtime в полночь всегда кратна 60. Это значит никаких leap seconds туда не вклинивали.
$ date --date='@867715199' --utc
Пнд Июн 30 23:59:59 UTC 1997
$ date --date='@867715200' --utc
Втр Июл 1 00:00:00 UTC 1997
$ date --date='@867715201' --utc
Втр Июл 1 00:00:01 UTC 1997
Та же самая картина. Т.е. получается, что не учитывается.
Вообще, заметьте, что unixtime в полночь всегда кратна 60. Это значит никаких leap seconds туда не вклинивали.
Вообще, заметьте, что unixtime в полночь всегда кратна 60. Это значит никаких leap seconds туда не вклинивали.
Это всё зависит исключительно от метода перевода UnixTime в UTC. Unix time не содержит в себе ни инфы о часовом поясе, ни инфы о высокосном году, ни инфы о leap seconds. Как вы не можете понять, единственное, что он содержит — количество секунд прошедших с 1970 года 1 января. А как переводить это время в человекочитаемый формат — вопрос другой.
Добавится еще одно правило для перевода из timestamp в date.
Куда добавится? Такого правила не может быть, timestamp никак не считает и не учитывает leap seconds. Он просто не предназначен для этого.
Скорее всего имеется ввиду новая версия tzdata
Намекаю.
Пусть timestamp x = 30.06.2012 23 ч 59 мин 59 с. Если никак не учитывать эту секунду, то x + 2 = 01.07.2012 00 ч 00 мин 01 с. Если добавить новое правило и учитывать ее, то x + 2 = 01.07.2012 00 ч 00 мин 00 с.
Или вы не собираетесь переводить timestamp в обычную дату?
Пусть timestamp x = 30.06.2012 23 ч 59 мин 59 с. Если никак не учитывать эту секунду, то x + 2 = 01.07.2012 00 ч 00 мин 01 с. Если добавить новое правило и учитывать ее, то x + 2 = 01.07.2012 00 ч 00 мин 00 с.
Или вы не собираетесь переводить timestamp в обычную дату?
Ой, ну всё выше уже обмусолили мы с VolCh (правда, он пытается что-то ещё обсудить, и будто не согласен с чем-то, а я реально не понимаю что именно я неправильно говорю, скорее всего просто о разном говорим?), больше и добавить нечего. Переводить собираюсь иногда, конечно. НО ничего не нужно учитывать. Поймите одно — учитывать ничего не надо, потому что И «обычная дата» И unixtime просто-напросто «оба два» не учитывают никакой leap second. Правили перевода такое (и оно корректное!):
x = 30.06.2012 23 ч 59 мин 59
x+1 = 01.07.2012 00 ч 00 мин 00 с.
и всё, дальше как обычно.
x = 30.06.2012 23 ч 59 мин 59
x+1 = 01.07.2012 00 ч 00 мин 00 с.
и всё, дальше как обычно.
Интересно, как это будет разрулено на серверах точного времени?
Выдать 60 секунд они не смогут, соответственно они должны будут быть переведены на 1 секунду назад… а что будет с бедолагами, запросившими текущее время ровно через 1 секунду после 30.06.2012 23 ч 59 мин 59 с?
Выдать 60 секунд они не смогут, соответственно они должны будут быть переведены на 1 секунду назад… а что будет с бедолагами, запросившими текущее время ровно через 1 секунду после 30.06.2012 23 ч 59 мин 59 с?
Ну будет ошибка синхронизации, через секунду будет еще один запрос, но который будет правильный ответ. Ничего страшного
Видимо получат 01.07.2012 00:00:00 и будут на секунду спешить до следующего обновления. А вообще RFC3399 «Date and Time on the Internet: Timestamps» эту ситуацию предусматривает и сервера, следующие ему, выдадут 2012-06-30T23:59:60Z если в них успеют эту информацию внести.
Тут тоже всё просто:
www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499
см. 5.3.4. What happens during a Leap Second?
www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499
см. 5.3.4. What happens during a Leap Second?
А что происходит, когда время на час назад переводят? Ничего страшного
Хорошо что суббота :) Можно дольше гульнуть
Служба вращения Земли, спонсор времени и поставщик пространства.
отосплюсь!
Вобще надо уже с 12-ричной системы переходить на 10-чную:
100сек с минуте 100 мин в часе 10 часов в день, секунду соответственно на коеффициент 0,864 умножить
с месяцами конечно не все так однозначно они к лунному циклу типа привязанны.
Один раз помучаться пересчитать, зато потом как удобно будет, не надо ничео считать, точку только в нужном месте поставил и все. Например 10 дней = 100кС*10дн=1Мс
100сек с минуте 100 мин в часе 10 часов в день, секунду соответственно на коеффициент 0,864 умножить
с месяцами конечно не все так однозначно они к лунному циклу типа привязанны.
Один раз помучаться пересчитать, зато потом как удобно будет, не надо ничео считать, точку только в нужном месте поставил и все. Например 10 дней = 100кС*10дн=1Мс
а зачем? И в чем проблемы со счетом?
Вобще, если кто не понял, это шутка была. Ну да ладно…
Проблемы действительно есть, например с ходу сказать сколько секунд в восьми часах или какая дата была 500 дней назад далеко не каждый сможет.
Так то оно так, но это все перечеркивается огромным гемороем внедрения: пересчитать, перепрограмировать, переименовать (чтоб не путаться), перепаять наконец. Потому это кроме как шуткой которую много кто не понял быть не может.
Если только придумать машину времени и изначально подсказать чтоб сделали так :) Ну или если марс колонзируем может им подойдет, но и то врятле прийдется ведь секунду менять а это пересчет всех формул, контант, значений…
Если только придумать машину времени и изначально подсказать чтоб сделали так :) Ну или если марс колонзируем может им подойдет, но и то врятле прийдется ведь секунду менять а это пересчет всех формул, контант, значений…
Не раньше, имхо, чем человечество начнёт массовую колонизацию Солнечной системы, как минимум, когда использование системы основанной на характеристиках Земли станут называть «великоземельным шовинизмом» :)
Только если с инопланетянами встретимся у которых изначально так было, у нас же на секунду очень много завязанно всего. Хотя у них может оказаться 14 пальцев на руках и тогда у них соответственно какая нибудь 14-рична система в почете будет, и под нее все подгонят. В принципе она и десятичная система хороша тем что мы к ней привыкли. ну и в силу физиологии нам ей пользоваться удобней.
Если связывать 12 часов с 10 пальцами, как Вы предлагаете для инопланетян с 14-ю… что-то у меня не сходится :)
Я так понимаю изначально время с созвездиями как то связали, почему их 12 насчитали конечно непонятно. Может по одному пальцу таки у нас было в древности а всячские палеонтологи ошибаются(загаовор, лол). Хотя в английском например изначально я так понимаю счет до 12-и был, а потом пошел в десятичной.
Кстати если б таки размер секунды менять можно было б какраз в них поправку уложить. :)
Надо поштудировать сей вопрос, как так получилось что 12-ричную взлюбили, может изза месяцев количества так получилось. А месяцы к луне привязанны +-.
Кстати если б таки размер секунды менять можно было б какраз в них поправку уложить. :)
Надо поштудировать сей вопрос, как так получилось что 12-ричную взлюбили, может изза месяцев количества так получилось. А месяцы к луне привязанны +-.
12 довольно удобное число для людей неизбалованных позиционными системами счисления с дробной частью — делится на 2, 3, 4 и 6.
Про 12-ричную систему я помню просто объяснение (только уж не полезу за пруфлинками). На четырех пальцах (кроме большого) 12 фаланг, и удобно большим указывать на любую из них. Можно даже соорудить из пальцев двухразрядный 12-ричный калькулятор, работающий по принципу счет с костяшками.
10 можно разделить только на 2 и 5 частей.
12 можно разделить на 2,3,4,6 частей.
12 можно разделить на 2,3,4,6 частей.
12 это вообще уникальное число.
Hex везде будет!!!
Да, и обязательно отменить часовые пояса, пускай на всей планете одинаковое время будет
Тогда уж чего мелочиться, изменим орбиту луны чтоб за 10 дней стадии менялись, и землю разгоним в году ровно 100 дней было. Гулять так гулять.
Или покроем планету каким нибудь нано-покрытием чтобы ночью делалось темным, а днем с одной стороны просзрачным, а с обратной отражающим, чтобы у всех в 00:00 была ночь, а в 5 часов ровно полдень. Только с ветрами что делать, поставим вентиляторы на термоядерных реакторах пусть гоняют, и холодильники на полюсах соорудим, чтоб не расстаяли.
Если днём назвать 3 вращения Земли вокруг своей оси, то луна будет оборачиваться вокруг Земли за 10 дней, а Земля вокруг солнца приблизительно за 100 дней (120). Тогда надо будет ускорять землю не в 3.6 раза, а всего в 1.2, что значительно реальнее.
Хм, это тогда просто вращение замедлим, но тогда получится 30 часов в день, наверное тогда лучше секунду видоизмененную на 3 умножить(примерно 2,592 нынешних) тогда все сойдется в минуте 100 сек, в часе 100 мин, в дне 10часов, в месяце 10дней, в году 10 месяцев, на руках 10 пальцев. красота. С богом еще переговорить чтоб скорость света чуть подогнал (вместо 115 660Км/с была 1Тм/с)
Чтобы в году было ровно 100 дней, совсем необязательно землю разгонять. Более простое решение это определиться на мировом уровне что такое день и что такое год
12 и 60 были выбраны не просто так. Они как раз удобнее, чем 10 и 100.
12 делится без остатка на 2, 3, 4, 12.
60 — на 2, 3, 4, 5, 6, 10…
12 делится без остатка на 2, 3, 4, 12.
60 — на 2, 3, 4, 5, 6, 10…
Чёрт, чего же мы раньше об этом не подумали? Не надо менять ничего в времяисчислении. Надо просто отрастить ещё 2 пальца!
[hipster=ON]По «плюс одному» на каждой руке — это попса. Надо по 25 на каждой отращивать :) [hipster=OFF]
Кстати таки в каждой шутке… А если правда попробовать попользоваться 10-чными часами (написать ПО для этого всего) только лишь не использовать общепринятые обозначения, например секунду назвать допустим декундой, остальные обозначения не обязательно придумывать можно просто приставки СИ использовать, кстать вот вики чего по поводу 12-60-ричной говорит.
Если народу понравится, собсно она сама вытеснит текущую.
Если народу понравится, собсно она сама вытеснит текущую.
Во-первых, есть Десятичное время, во-вторых, есть Интернет-время
А можете пояснить?
«Секунды координации с 1972 года добавляются к декабрю или июню, чтобы время UTC не отличалось от UT1 более, чем на 0,9 с.»
…и там же
«Разница между UTC и международным атомным временем:
с 01.01.2009 00 ч UTC до 01.07.2012 00 ч UTC: UTC-TAI = -34 с».
Как это разница в 34 секунды, но при этом не более чем на 0,9.
«Секунды координации с 1972 года добавляются к декабрю или июню, чтобы время UTC не отличалось от UT1 более, чем на 0,9 с.»
…и там же
«Разница между UTC и международным атомным временем:
с 01.01.2009 00 ч UTC до 01.07.2012 00 ч UTC: UTC-TAI = -34 с».
Как это разница в 34 секунды, но при этом не более чем на 0,9.
Из вики:
Атомное время — это UTC-TAI, вот разница между UTC и UTC-TAI = -34 с, а между UTC и UT1 — 0.9 с
Всеми́рное координи́рованное вре́мя (UTC) — стандарт, по которому общество регулирует часы и время. Отличается на целое количество секунд от атомного времени и на дробное количество секунд от всемирного времени UT1.
Атомное время — это UTC-TAI, вот разница между UTC и UTC-TAI = -34 с, а между UTC и UT1 — 0.9 с
А Мюнхгаузен то был прав!
Вы со стороны попробуйте посмотреть на этот топик, оцените юмор. Толпа людей строчит комментарии о том, что где-то там у кого-то там секунда лишняя возникла.
кстати да… у меня же 30го свадьба :)
это я удачно)
это я удачно)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
30 июня 2012 г. будет на секунду длиннее: 23:59:60