Исходное сообщение
"Разработчики ядра Linux обсуждают возможность удаления Reise..." Отправлено _kp, 27-Фев-22 01:49
Это придумали в стародавние времена для весьма древних компьютеров со скромными возможностями. На момент создания такого формата времени это было вполне удачное решение. Да можно было заложить бесзнаковый тип,  и это даже часто используется, что отодвигает проблему, вроде бы на 2106 год. Но, на то время нужнее были даты на весь двадцатый век, а не после 2038 года. Тогда ОС часто кардинально менялись, и не планировалось, что именно такой формат данных будет вечным. В принципе, как только стали получать распространение 64х битные системы, надо было сразу для них ввести _новый_тип_ для времени, и новые функции его использующие, а не вносить бардак с переименованим размерностей. Так и 32х битные системы плавно бы переползли на новый формат времени, и 64х битные сохранили совместимость со с историческим time_t. Постепенно старые программы бы заменялись, и уже сегодня о проблеме бы даже забыли. Похожая глупость была в Delphi, когда при введении юникода изменили размер существующего тип string, вместо введения нового типа, якобы что бы не меняя программы, можно было только пересобратб исходник, но на деле вышло с точностью до наоборот - полная несовместимость исходников, и необходимость многочисленных правок. А в С и С++ добавили новые типы, и функции и проблемы вообще не возникало.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Это придумали в стародавние времена для весьма древних компьютеров со скромными возможностями. > На момент создания такого формата времени это было вполне удачное решение. > Да можно было заложить бесзнаковый тип, и это даже часто используется, > что отодвигает проблему, вроде бы на 2106 год. > Но, на то время нужнее были даты на весь двадцатый век, а > не после 2038 года. > Тогда ОС часто кардинально менялись, и не планировалось, что именно такой формат > данных будет вечным. > В принципе, как только стали получать распространение 64х битные системы, надо было > сразу для них ввести _новый_тип_ для времени, и новые функции его > использующие, > а не вносить бардак с переименованим размерностей. > Так и 32х битные системы плавно бы переползли на новый формат времени, > и 64х битные сохранили совместимость со с историческим > time_t. > Постепенно старые программы бы заменялись, и уже сегодня о проблеме бы даже > забыли. > Похожая глупость была в Delphi, когда при введении юникода изменили размер существующего > тип string, вместо введения нового типа, якобы что бы не меняя > программы, можно было только пересобратб исходник, но на деле вышло с > точностью до наоборот - полная несовместимость исходников, и необходимость многочисленных > правок. > А в С и С++ добавили новые типы, и функции и проблемы > вообще не возникало.
	Введите код, изображенный на картинке: