Как то прошло незамеченным, что несколько часов назад началась новая "эра", как минимум на наших железках всех мастей.
Я не перепил, если что...
PoC (несколько часов назад):
$ date +%s
1499999999
$ date +%s
1500000000
$ date +%s
1500000001
Маленький юбилей, ибо мы разменяли полтора лярда секунд с начала времен эпох.
Посему, с Праздником всех! Холодного и вкусного пива! Безбажного кода! Тихо шуршащего железа! И да обойдут вас вируса стороной!
Следующая новая эпоха (1600000000) состоится через три человеческих года, а именно "Sun Sep 13 12:26:40 GMT 2020".
Следующая же юбилейная секунда отсчитает только в "Wed May 18 03:33:20 GMT 2033" и разменяет уже два миллиарда.
Как оно всё сложится...
Комментарии (24)
TyVik
14.07.2017 14:33+1Эх, и вот такой вот запоздалый подарок ко дню программиста будет в 2020 году.
LoadRunner
14.07.2017 14:39А в каком году случится переполнение переменной?
sebres
14.07.2017 14:47+4Уточните тип, пожалуйста...
0x7fffffff => Tue Jan 19 03:14:07 GMT 2038 0xffffffff => Sun Feb 07 06:28:15 GMT 2106 0x7fffffffffffffff => Sun Apr 24 15:30:07 GMT 1583316 ...
sebres
14.07.2017 17:01+1Опа! Бага нашлась! Видать софтина которая тут пользовалась где-то чего-то переполняет при расчете (подозреваю что собственно год или количество julian days)…
Т.к. год много больше должен быть в случае__int64
:
1970 + 0x7fffffffffffffff / int(365.25 * 24*60*60) == 1583316 292271025015 != 1583316
Torronir
16.07.2017 18:19У Вас небольшая ошибка. Вы взяли основание из Юлианского календаря. В григорианском другое правило для определения высокосного года — год является високосным в двух случаях: либо он кратен 4, но при этом не кратен 100, либо кратен 400 (2100, 2200, 2300 — не высокосные). Правильное основание будет 365,2425.
sebres
16.07.2017 18:21я стесняюсь спросить — вы число Пи до которого знака пишете?
А по теме, кто его знает как високосные года через столько лярдов лет считать начнут...Torronir
16.07.2017 19:25-1Зависит от чисел с которыми приходится работать. Когда диаметр круга больше 10 метров, то эти 15 милиметров могут потом дорого стоить. У вас же погрешность в 0.0075, даже в бухгалтерских програмах обычно считают точнее.
Если по теме, то с учетом того что теперь 1 день разницы набегает за 10 000 лет, то максимум введут что каждый 10 000 год — невысокосный. Но скорее всего просто календарь потеряет свой смысл из-за своей привязки только к одной планете в одной звездной системе.sebres
17.07.2017 09:42Вы правда считаете что для пруфа 290 лярдов != 1.5 мильена важно что там в каком-то шестом порядке стоит?
Ну-ну...Torronir
17.07.2017 15:02+1Нет, я вообще не об этом. Там и так понятно, что какой-то баг.
Я только обратил ваше внимание на небольшую ошибку в формуле. Что-то Вы слишком болезненно ее восприняли.
denissimo74
14.07.2017 22:07Хороший повод бутылочку чего-то ни было.
EugeneButrik
15.07.2017 11:26Сначала пишем, а потом уже можно "бутылочку чего-то ни было", а то сплошной Т9 получается :)
gnomeby
15.07.2017 11:53В некоторых проектах, где я работал, использовалась регулярка для проверки на unixtime следующего вида:
1\d[9]
Есть подозрение, что в 2033, нас ожидают сюрпризы.
iassasin
15.07.2017 16:50+1Следующая новая эпоха (1600000000) состоится через три человеческих года, а именно «Sun Sep 13 12:26:40 GMT 2020»
Кажется, я начал понимать, почему новые стандарты C++ выходят раз в три года…
SysCat
Оригинально! Поздравляем!
sebres
Ну так совпало. Пятница… повод...