trouble 2038

Нигде, конечно же. :)

https://ru.wikipedia.org/wiki/Проблема_2038_года

В старых 32-битных системах (до середины 1990-х) используется тип данных time_t для хранения секунд в виде 32-битного целого со знаком. Самая поздняя дата, которая может быть представлена таким форматом в стандарте POSIX — это 03:14:07, вторник, 19 января 2038 года по Всемирному времени (UTC).

…

Я не про это, оно считается от 01.01.1970, эту изменить что мешает ? И отодвинуть проблему еще лет на 30-50.

Да уже нельзя изменять. И на ближайшие 292 млрд. лет проблема решена на 64-битных ОС.

Аналогия: попробуйте изменить дату своего рождения/имя/фамилию во всех документах.

Аналогия: попробуйте изменить дату своего рождения/имя/фамилию во всех документах.

Скорее, это как передвинуть ноль в шкале Цельсия.

Скорее, это как передвинуть ноль в шкале Цельсия.

Вообще то там не 0 двигается, а дата взятая с потолка. 01.01.1970

И если 0, даже 36.6 это по сути конкретные температуры, то 01.01.1970 вообще ничего не значит. Главное чтобы к этому числу приращение укладывалось в 32 бита.

Вообще то там не 0 двигается, а дата взятая с потолка. 01.01.1970

Это и есть ноль в системе отсчета Unix time

И если 0, даже 36.6 это по сути конкретные температуры, то 01.01.1970 вообще ничего не значит

Ноль по Цельсию тоже довольно криво определен, и опирается на «магическую» константу 0.01

Это и есть ноль в системе отсчета Unix time

Ответь тогда мне на простую задачу (ну в том старом варианте):

Сколько сейчас время если прирост времени 5 секунд ( в той самой переменной стоит цифра 5). Это я так грубо, но чтобы понятнее было.

Скорее, это как передвинуть ноль в шкале Цельсия.

Гениально! Решена проблема глобального потепления!

Ты ещё спроси, почему двух цифр недостаточно для записи года.

Сколько сейчас время если прирост времени 5 секунд ( в той самой переменной стоит цифра 5)

Похоже на задачу про «сколько лет капитану»

И отодвинуть проблему еще лет на 30-50.

И получить проблему прямо сейчас.

И получить проблему прямо сейчас.

Почему ? 70 + 50 = 2020 г. т.е. все переносится на 2088 год …

Как работать с датами, предшествующими 03:14:07 UTC 19 января 2038 года?

А что делать с уже существующими данными, использующими Unix Time?

В шредер

Потому что все те программы, которые ожидают, что начало эпохи было в 1970-м, внезапно обнаружат себя в конце семидесятых. А что будет, если они при этом таймеры и диапазоны рассчитывают — сам подумай.

которые ожидают, что начало эпохи было в 1970-м,

Возвращаемся к началу. А с чего они ожидают что начало эпохи в 1970 ?

Потому что так было написано в стандарте ещё в 1969.

Всей планете перейти на юлианскую дату. Жаль, что рулят не астрономы.

Почему его нельзя просто поменять ?

Представь, что у тебя в БД приложения даты хранятся в unix time. Если ты сдвинешь начало unix эпохи на, скажем, 30 лет вперед - твой свежесозданный вчера аккаунт получит created_at от 2052 года.

Много софта умрет, который рассчитан на подсчет секунд с 1970 года

К тому же, есть патчи, которые делают это время 64-битным даже на 32-битных платформах Linux

И есть библиотеки типа libfaketime которые призваны помочь тестировать софт на подверженность проблеме, если к нему нет исходников и нет шанса поправить

Это не поможет.

01.01.1970 это константа используемая в куче алгоритмов работающих с датами. Плюс данные относительно этой даты сохранены в куче файлов. То есть тебе надо перекомпилировать все программы и конвертировать все файлы. Но если так заморачиваться, то почему бы просто не заменить используемый тип данных на 64-битный и точно также решить проблему? При этом это даже менее трудоёмко будет, потому что 99% алгоритмов пофиг какой разрядности дата. И заодно решишь проблему раз и навсегда (ну, на срок жизни солнечной системы точно, а в межзвёздных путешествиях всё равно другое время нужно будет).

Плюс в варианте переноса базиса есть проблема с историческими данными, так как некоторые информационные системы вполне себе хранят даты из 70-80-х годов.

Я не про это, оно считается от 01.01.1970, эту изменить что мешает ?

Это будет означать инвалидацию всех существующих таймстемпов. Т.е. софт считающий за ноль 1970 и софт считающай за ноль другую дату не смогут корректно взаимодействовать.

И отодвинуть проблему еще лет на 30-50.

Зачем, когда её можно и нужно решить раз и навсегда? Столько уже страдали из-за таких уродов-отодвигателей: CHS, IPv4, UCS2, указатели банальные…

Его можно в бине заменить …

1. Они взаимодействуют выходными данными а не внутри.
2. Т.е. из уродов что двигают страдать плохо, а из за уродов что мы юзаем говно процессоры не с прямой адресацией страдать - нормально. Ага. Меня всегда удивляляло что в 90х по сути похоронили нормальные процы с прямой адресацией и взялись за это гавно что на 40МГц еле дотягивали до тех прямых типа 68000, с 7 МГц.

Я не про это, оно считается от 01.01.1970, эту изменить что мешает ? И отодвинуть проблему еще лет на 30-50.

Это будет временным решением проблемы, костылём. Лучше и проще будет решить проблему 64-битным числом что позволит отодвинуть проблему не на 30-50 лет, а на 292000000000 лет.

Ну так это только для старых прог, что думаете остануться еще такие проги в то время что будут юзатся под те современные ос ?

Учитывая что 32-битные системы на момент 2023 года в пользовательских и enterprise нишах практически закопаны вряд ли через 13 лет эта проблема будет актуальна.

Вот на различных инфраструктурных объектах действительно могут быть некоторые проблемы.

Если ее отодвинуть – нулем по юникс-тайм одни программы будут считать 01.01.1970, а другие, скажем, 01.01.2023. Ну и 68 лет – это не так уж много. Может, подавляющее большинство лоровцев и не доживут до 2089 года, а встраиваемые системы на всяких атомных электростанциях доживут.

Вот на различных инфраструктурных объектах действительно могут быть некоторые проблемы

За 13 лет можно сертифицировать новую версию софта для работы на имеющемся железе. Если, конечно, не просирать деньги налогоплательщиков на поповские капища и дорогие яхты.

Если ее отодвинуть – нулем по юникс-тайм одни программы будут считать 01.01.1970, а другие, скажем, 01.01.2023

Но тогда возникает проблема, как отличать друг от друга time_t с разной точкой отсчета. Это же просто целые числа. Допустим, у файловых систем можно ввести новые ферсии форматов хранения (для каждой ФС в мире это придется делать отдельно) и использовать в новом формате новую базу. У сетевых протоколов тоже можно поднять версию, но это потребует изменения приложений и библиотек, реализующих эти протоколы. Но что делать с другими данными, например, лежащими в виде полей в базах данных? Они останутся в «старом» формате, и для сравнения их с «новыми» таймстемпами придется городить костыли.

Вот поэтому и проще перейти на 64-битный time_t. Это даже не требует замены железа. 64-битное время может работать на 32-битном процессоре. Нужно обновить софт и сертифицировать его для эксплуатации на объекте.

Естественно. Увеличение битности переменной никак не меняет логику работы старых программ и способ интерпретации существующих данных.

Учитывая что 32-битные системы на момент 2023 года в пользовательских и enterprise нишах практически закопаны вряд ли через 13 лет эта проблема будет актуальна.

Ничто не мешает использовать 64-битные time_t на 32-битных системах. И да, никто не собирается их закапывать, на эмбедщине с малениким количеством оперативки 64 бита никому на хрен не упали.

Они взаимодействуют выходными данными а не внутри.

Не могу даже представить что скрывается за этой глубокой мыслью. Unix time используется везде - и в runtime состоянии, и для персистентного хранения, и для передачи информации. При несогласованном изменении точки отсчёта (а её физически невозможно согласованно изменить во всём используемом софте и железе) получим смещённое время абсолютно где угодно.

Меня всегда удивляляло что в 90х по сути похоронили нормальные процы с прямой адресацией и взялись за это гавно что на 40МГц еле дотягивали до тех прямых типа 68000, с 7 МГц.

А меня всегда удивляло как люди не способные построить в голове модель работы с одним сраным интом считают что могут иметь мнение о процессорных архитектурах.

Тут вообще как то странно все. Если подумать то не совсем понятно как синхронизируется время у таких программ. Они что принимают на вход после включения и откуда … в смысле сеть/биос.

Давай те так, если Вам тема интересно то пишите по теме если нет то лучше не писать. Мне не интересно с вами обсуждать у кого какой уровень и обьяснять что писать на асме не зная архитектуру проца не возможно.

Если подумать то не совсем понятно как синхронизируется время у таких программ.

Чтобы пользоваться unix time, вообще не обязательно синхронизировать часы. Это вполне конкретные дата и время, записанные в виде целого числа, и их интерпретация никак не зависит от текущих показаний системных часов.

Давай те так, если Вам тема интересно то пишите по теме если нет то лучше не писать. Мне не интересно с вами обсуждать у кого какой уровень и обьяснять что писать на асме не зная архитектуру проца не возможно.

Но это вы начали никак не связанную с темой шизофазию про 68000 и ассемблер, а сейчас вот написали сообщение где по теме нет вообще ни слова, в котором просите не писать сообщений в которых по теме нет ни слова? Ладно, про unix time у вас ещё есть вопросы или гениальные идеи?

Да но комп/прогу могут выключить на какое то время …

Допустим, у тебя есть термометр и ты каждый день записываешь его показания в журнал. Если он сломается, или его засыпет снегом и он не будет показывать правильную температуру, на смысл твоих предыдущих записей это никак не повлияет. Точно так же задача отслеживания текущего времени не имеет прямого отношения к использования таймстемпов.

И к чему это ты написал ?

Ну раз ты совсем не понимаешь, что такое таймстемпы и как их используют

А ты немного подумай и поймешь про что я… Если не понимаешь то я могу подсказать.