Это мой второй вопрос по DateTime. Мы тестируем наше приложение на все известные возможности ошибок. Я столкнулся с этой проблемой год назад и после долгих исследований опубликовал статья на CodeProject по этой теме. Эта статья объяснит, что такое ошибка 2038 года и как она может исправить многие из наших приложений завтра. Подробное объяснение ошибки 2038 года выходило за рамки этого вопроса, поэтому я сослался на статью, написанную только мной.
Текст ссылки: http://www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx
Какие приложения (серверные приложения, клиентские приложения, инфраструктурные решения s / w и h / w), которые мы используем в настоящее время, уязвимы для этой ошибки?
Какие есть решения для ошибки 2038 года? Как можно обновить наши решения и приложения, чтобы справиться с этой проблемой?
Это очень футуристический вопрос, но его стоит обсудить.
Я полагаю, что наибольшему риску будут подвержены небольшие встроенные системы. Это небольшие системы, которые управляют нашими лифтами, GPS-приемниками, автомобильными компьютерами и т. Д. Многие из этих устройств все еще будут работать в 2038 году без возможности «выйти в Интернет» для проверки обновлений прошивки.
Короткий ответ - почти любая 32-битная ОС, использующая временные метки unix.
Некоторые 32-битные версии были исправлены для использования 64-битного времени, однако это всегда только вариант.
Точно так же некоторые 64-битные ОС по-прежнему используют 32-битный time_t и поэтому все еще открыты для переноса.
Я думаю, что за 30 лет до того, как проблема возникнет, спекулировать неразумно. Убедитесь, что все новое использует 64-битные метки времени, и к 2038 году будет очень мало использования 32-битных меток времени.
У меня такое чувство, что нам намного хуже, чем мы думаем:
К 2038 году time_t, конечно, будет иметь ширину 64 бита в большинстве систем (просто вспомните, где мы были 30 лет назад), так что это не имеет особого значения.
То, что я считаю гораздо большей проблемой, - это наличие множества протоколов, которые указывают 32-битные временные метки как часть своей внутренней работы. NTP, SSL - выбирайте сами.
Даже когда мир изменился и все используют 64-битные машины, эти протоколы обязательно будут использоваться (SMTP был введен около 30 лет назад и до сих пор широко используется, тогда как оборудование, представленное тогда, на самом деле нет - просто для того, чтобы указать здесь).
Какие приложения (серверные приложения, клиентские приложения, инфраструктурные решения s / w и h / w), которые мы используем в настоящее время, уязвимы для этой ошибки?
Оборудование в основном не затрагивается напрямую, большинство микросхем часов реального времени не работают в unix-time. Даже если они это сделали, есть относительно простые обходные пути. Это в первую очередь программная проблема.
Это сильно влияет на большинство 32-битных Unix-подобных систем и приложений, работающих на них. У них 32-битный time_t является центральным компонентом платформы ABI.
64-битные Unix-подобные системы обычно используют 64-битное время в качестве основного представления, поэтому они не так сильно затронуты, но некоторое влияние все же вероятно из-за небрежного кода, который передает время с использованием неправильных типов данных или из-за файла форматы, разработанные для 32-разрядной версии Unix.
Какие есть решения для ошибки 2038 года?
Обычное решение - заменить 32-битное время на 64-битное время. Насколько это сложно, зависит от сценария. Если это просто внутренняя переменная или параметр, который не отображается ни в одном стабильном внешнем ABI, то это довольно легко исправить.
С другой стороны, заменить его в платформе ABI трудно без «знаменательного дня», когда все должно быть перестроено сразу, или создания двух отдельных миров устаревшего программного обеспечения и текущего программного обеспечения с полностью отдельными наборами библиотек.
Это можно сделать с помощью подхода, аналогичного тому, который используется для поддержки больших файлов, но время распространяется гораздо шире через библиотеки платформ, чем размер файла.
Для форматов файлов, вероятно, потребуется переходный период. Сначала определяется новая версия формата, затем необходимо обновить программное обеспечение, чтобы прочитать новый формат. Наконец, программа должна начать запись файлов в новом формате.
В некоторых ситуациях альтернативным решением может быть использование 32-битной версии, но изменение временного окна, например, если вы знаете, что ваша система не будет иметь никаких временных меток до 1970 года и не использует отрицательные числа в качестве значений флагов, вы можете выбрать перейти к 32-битному беззнаковому количеству.
Как можно обновить наши решения и приложения, чтобы справиться с этой проблемой?
Для полноразмерных серверов вы, вероятно, уже используете 64-разрядную ОС, поэтому базовые компоненты базовой платформы уже должны быть там, и вы можете сосредоточиться на поиске проблем в своих приложениях. Раскрутите сервер с датой в будущем и посмотрите, что сломается.
Для встроенных вещей, где использование 64-битной ОС нецелесообразно или даже возможно, все выглядит гораздо менее радужно. До тех пор, пока / пока основные библиотеки и дистрибутивы не разберутся со своей стороной, сложно что-либо сделать на уровне приложения.