Просто из любопытства, что будет с RPis Model A и B 19 января 2038 года в 3:14:07 по Гринвичу? На них влияет ошибка Y2K38 ?
hardware
system-clock
bugs
Дагхостман Димитров
источник
источник
time_t
, превращая это в проблему Y292G , которую не увидим ни мы, ни солнце.Ответы:
Да.
Вот вывод SSH-сессии для моего Pi с запущенным OpenELEC.
Зависает после достижения Y2K38. Не только сам сеанс SSH перестает отвечать, но и OpenELEC зависает.
Я ожидаю (и надеюсь!), Что к 2038 году будет выпущено исправление.
Это, или ваш вопрос получит много голосов через 24 года.
источник
На самом деле Raspberry Pi (аппаратное обеспечение) будет в порядке. Он не содержит RTC, поэтому он будет зависеть от того, какую ОС вы используете.
Но IIRC все 32-битные версии Linux имеют эту проблему. Некоторое время назад (10 лет или около того) Линус сказал, что ему неинтересно исправлять это на 32-битных платформах, и на всех 64-битных платформах Linux в то время было 64-битное time_t. Конечно, с тех пор он, возможно, изменил свое мнение. Лучшая ссылка, которую я могу найти, - это http://permalink.gmane.org/gmane.linux.kernel/1184914, которая не совпадает, но выражает аналогичные намерения.
Это не будет особенно сложно изменить, но это вызовет изменение в ABI ядра. Что само по себе является проблемой.
Но RiscO использует 40-битное время (центсекунда), но с другой эпохой. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - я совершаю этот провал где-то в 2318 году - [calc был: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365,25)]
Android, конечно, использует ядро Linux. И я уверен, что пропустил другие варианты.
источник
Как и в настоящее время реализовано, Raspberry Pi будет страдать от судьбы перечисленной ошибки, если не будет внесено никаких изменений в программное обеспечение.
Большинство современных машин переходят на 64-битные процессоры, но я бы не удивился, увидев в тот момент 32-битные процессоры с мейнстримом. Существуют программные решения, которые могут и должны будут решить проблему.
Мне кажется, что наиболее вероятным решением было бы обновить время Epoch, чтобы оно началось примерно с 1 января 2000 года. Хотя это не задержит ошибку, она наверняка сбросит ее в обозримом будущем.
источник