обратная! :) В одной на пипке плюс, а в другой минус. Сомневаюсь, что многим приборам-потребителям таких батареек это понравится.
Тоже дежавю возникло, читал с месяц назад про эти батарейки и тоже помню про обратную полярность.
Так-то всё верно. Но сохранить язык можно только сохранив кол-во людей на нём говорящих. Что, понятно, невозможно, раз уж язык начал умирать. Можно как угодно рассматривать язык, но первым делом это лишь инструмент. Как и любой другой, если он станет не нужен — он умрёт и забудется. Ну или займёт своё место в музее. Более чем инструмент он интересен языковедам и лингвистам всяким, они то будут его изучать в качестве истории, если он представляет такой интерес. Особого смысла сохранять то, что умирает естественным путём я не вижу.
Ну да, не влияют, если правильно понял фразу, то это то о чём я и пытаюсь сказать выше и ниже. Но всё же «виртуально» будет как будто бы дважды подряд именно в это время. «Реально» же это будет так только в тех местах, где это вообще будет заметно. То есть те, кто знает про это, тикнет именно таким образом. А те, кто не знает — ничего не заметит, всё верно сказали — синхронизируют эту секунду потом (это же и по ссылке на ntp.org ниже написано). В любом случае перевод unixtime -> «настоящее время» останется как был и эти секунды там никогда не проявятся. Для 1341100800 прямое однозначное соответствие будет 00:00:00 и всё.
Ой, ну всё выше уже обмусолили мы с VolCh (правда, он пытается что-то ещё обсудить, и будто не согласен с чем-то, а я реально не понимаю что именно я неправильно говорю, скорее всего просто о разном говорим?), больше и добавить нечего. Переводить собираюсь иногда, конечно. НО ничего не нужно учитывать. Поймите одно — учитывать ничего не надо, потому что И «обычная дата» И unixtime просто-напросто «оба два» не учитывают никакой leap second. Правили перевода такое (и оно корректное!):
x = 30.06.2012 23 ч 59 мин 59
x+1 = 01.07.2012 00 ч 00 мин 00 с.
и всё, дальше как обычно.
Хм, командная строка сказала, что должны проходить. Сейчас накидал программку на java — она тоже сказала, что должны проходить. А что, не проходит что ли? Я привёл реальные пары unixtime -> время в UTC (не реальное «настоящее» время в UTC, для которого и делается эта поправка, а именно его представление этому значению unixtime, т.е. то что вы всегда получите в компе).
Ваш пример не будет проходить, конечно. Реально там было три високосных года, потому на три дня и сместится вперёд (на 4 июля). А секунды то останутся нулевыми.
Если говорить именно о переводе времени из unixtime в «удобочитаемый вид» в UTC, то да. Вроде, понял что имеете ввиду. Просто смутило — речь пошла о том, что вроде как в unixtime вдруг день окажется 86401 секунды. Реально же, ну что поделать — для 1341100799 покажет 23:59:59, для 1341100800 — 23:59:60 и для 1341100800 ещё раз 00:00:00 и всё пойдёт своим чередом. Да, мы будем знать что реально когда-то именно этот день был дольше на 1 секунду, но это всё — более НИГДЕ реально вы этого никогда не увидите. Ни в компьютерных программах, ни в календарях, нигде. При операциях над unixtime вычитаниях итд итп, вы всегда получите разницу нормальную, как будто не было никакой секунды. О этом и речь, что оно не учитывается нигде. И календарность не сломается. Эта секунда прибавится к уже набежавшим за последние десятилетия десяткам таких секунд и будет использоваться в других местах, и довольно активно.
Как раз дело в том, что unixtime тупо не предназначен для точных расчётов времени. Это просто представление UTC относительного определённой временной метки, расположенной в прошлом (тоже в UTC в 1970 году). Используется для удобной конвертации между таймзонами и удобного представления. Соответственно, он и не применяется в явном виде во всяких GPS, NTP и т.п., там своя синхронизация по всяким TAI, напрямую относительно UT1 итд итп.
В любом случае leap seconds не учитываются (и не могут просто физически) в unixtime, это факт. Зачем же спорить с очевидным :)
Ну нет же, как раз не именно! :) Этого в unixtime не может быть принципиально. Високосный год — пример неподходящий — високосные дни заранее распланированы и, понятное дело, учитываются, ибо это дело календарной важности. А leap seconds не учитываются по определению и в unixtime день всегда 86400 секунд длится.
Да почему неверные то? А как должно быть, по-вашему? Как раз тут всё корректно.
Т.е. разница между датами «Пт. июня 1 00:00:00 UTC 2012» и «Вс. июля 1 00:00:00 UTC 2012», выраженных в unixtime должна составлять не 30*24*60*60, а 30*24*60*60+1? :)
Тоже «осилил», просто из принципа уже. Думал — ну чем же это закончится. Изложение мечется от философствования до додумок. Сравнивать программы с жизнью, конечно, можно. Но тогда все вещи вокруг человека можно назвать живыми. Они тоже делаются, тоже проходят какой-то естественный отбор, усложняются итд итп. Книги, например — их человек так же создаёт, множит, продаёт, распространяет, отстойные забывает итд итп. Так что ничего тут нового не появилось с этой точки зрения.
Тоже дежавю возникло, читал с месяц назад про эти батарейки и тоже помню про обратную полярность.
x = 30.06.2012 23 ч 59 мин 59
x+1 = 01.07.2012 00 ч 00 мин 00 с.
и всё, дальше как обычно.
Ваш пример не будет проходить, конечно. Реально там было три високосных года, потому на три дня и сместится вперёд (на 4 июля). А секунды то останутся нулевыми.
В любом случае leap seconds не учитываются (и не могут просто физически) в unixtime, это факт. Зачем же спорить с очевидным :)
www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499
см. 5.3.4. What happens during a Leap Second?
Т.е. разница между датами «Пт. июня 1 00:00:00 UTC 2012» и «Вс. июля 1 00:00:00 UTC 2012», выраженных в unixtime должна составлять не 30*24*60*60, а 30*24*60*60+1? :)
з.ы. о, круто, оповещение об упоминании пришло на почту)