Правая Рука17.12.202417:46ссылка
SobakaBalabaka17.12.202417:47ссылкаНе говорите автору про timestamp.
в миллисекундах не учитывался, все верно
Тогда как ты объяснишь это?
*картинка сверху*
"Программисты в 2038-ом году когда int переполнится и превратится в –2147483648"
Ты хотел сказать, программисты через 290 миллиардов лет. Потому что с переходом на 64-битный формат срок передвигается примерно на столько.
Все, кто следуют спецификации POSIX. Например. И там не год хранится, а unixtime - т.е. секунды с начала эпохи.
блин в разных языках и компиляторах он разным может быть
Integer 4 bytes (using 32-bit compiler) -2147483648 to +2147483647
Integer 8 bytes (using 64-bit compiler) -9223372036854775808 to +9223372036854775807
Я как-то integer считаю 4-байтным. 8 байт это long, 2 - short.
как знать, эксель и аналоги, судя по всему, были сотворены 1 января 1900 года
всего один бит и вот у тебя уже есть возможность задать 292275241 год до Р.Х. (Пермский период, что забавно)
Максимальная дата, которая представляется с помощью "unix timestamp" - 19 января 2038 г. Ещё на нашем веку посмотрим на "программистов, знающих про timestamp". Статья в википедии уже есть - https://en.wikipedia.org/wiki/Year_2038_problem
И чо делать?
добавить ко всем датам в бд таймдельту лет на 5 и уволиться через 4
Увеличить вместимость поля в байтах с 4 до 8. Доживет до 292277026596 года
Переходить на int64 для таймштампов
Собственно, уже
Срочно переходить на формат даты с 4мя цифрами в годе. Тогда проблемой будут заниматься следующие поколения.
Ничего. Не слушать тех кто умеет в только в википедию. Для примера:
time.localtime(199999999999))
time.struct_time(tm_year=8307, tm_mon=10, tm_mday=1, tm_hour=22, tm_min=33, tm_sec=19, tm_wday=1, tm_yday=274, tm_isdst=1)
Просто для примера. Девяток можно и добавить.
Проблема в том, что в многих языках, библиотеках и существующем софте твоя хуебратия с девятками превратится в 284020828. А это было в 79-м году.
Ну, если это легаси доживёт до 2038, то, конечно ему респект, но уже пора бы и обновить. Оно уже сейчас легаси.
Ходят байки, что много банковских систем на кобальте, и обновить их стоит лярды и лярды денег https://habr.com/ru/articles/532554/
Уже ничего, переменную заменили на 64-битную
Ну, многое от точности зависит. Чем больше хранить чисел в дробной части секунд - тем ближе конец 64-битного даты-времени, очевидно.
А с ним в все тоже не так уж просто. Там уже даже на 128bit ные компы, а 256bit ные нужны будут. В прочем не серьезная проблема для 9999 года
Это не программисты, а директора их фирм
Тогда уж директора магазинов. Но программисты и сисадмины тоже немало профита получили. Потому что хер ты замену старому оборудованию выбъешь, все на рухляди работало. И когдаты начальник, и твой компьютерщик приходит и говорит про нее, и что надо обновляться, а ты нихрена не понимаешь, но слышал даже из телевизора, что все превратится в тыкву, деньги нехотя, но все-таки даешь.
Ты говоришь о "проблеме 2000", я говорю о "проблеме 2038"...или ты думаешь, там тоже придется железо менять?
А всё, поздно теперь, теперь эсцопе, самосбор и парачка подобных вселенных слепшенные воедино.
Мы живем в матрице, после 2038 года будет вайп, и начнём снова с 1970
Главное, чтобы не вайп неграми.
Знаю я ваш "вайп"
А потом внезапно окажется что управляющие терминалы межгалактической метро работают на софте написанной на GOBOL-е под Windows 3000
Христос Прокрастинатор - 5 лет не хотел заступать в обязанности
Он так-то до 30 лет хуи пинал.
А что если отсчет с 0 года начался именно потому, что не смогли после 9999 года настроить дату?
Своими - потому что у мисье девопса лапки.
|
|
|
|
|
 | it-юморРейтинг: 103,055.3 |
 | программированиеРейтинг: 17,617.8 |
 | geek pornРейтинг: 2,854.0 |
 | матанРейтинг: 2,617.0 |
 | Приколы для математиковРейтинг: 2,334.9 |
Не говорите автору про timestamp.