Проблема 2038 года [закрыто]

Какова вероятность того, что проблема 2038 года будет очень проблематичной?

Я столкнулся с этой проблемой во встроенной системе Linux, которая должна была обрабатывать даты после 2038 года в некоторых долгосрочных криптографических сертификатах, поэтому я бы сказал, что вероятность этого зависит от области вашего приложения.

Хотя большинство систем должно быть готово задолго до 2038 года, если вы сегодня рассчитываете даты в будущем, у вас могут возникнуть проблемы.

Я думаю, что это будет серьезной проблемой, гораздо более пагубной, чем проблемы 2000 года 1999/2000 года, потому что уязвимый код обычно является более низким уровнем (это CTIME), и поэтому труднее определить места, где время хранится таким образом.

Чтобы еще больше усложнить ситуацию, тот факт, что Y2K воспринимался как влажный болван, затруднит привлечение внимания к проблеме в преддверии события.

Культурные ссылки:

Кори Доктороу пробовал новую модель для ввода / публикации коротких рассказов под открытыми лицензиями, и я предложил тему 2038 года для одной из них, которую он блестяще сделал в эпоху: http://craphound.com/?p=2337

Несколько лет назад уже были сообщения о проблемах в таких областях, как ипотечные программы, производящие расчеты по 30-летним кредитам: 2008 + 30 = 2038.

64-битная ОС в конечном итоге не имеет отношения к проблеме 2037 года. (CTIME заканчивается ближе к 2037 году, чем к 2038 году).

Вопрос не в глубине операционной системы, а в том, как ОС хранит время. Или как столбец базы данных выбрать для хранения времени. Или как этот атрибут времени службы синтаксиса справочника хранит время на сервере.

Это гораздо более серьезная проблема, чем думают люди, поскольку она настолько распространена и распространена, что используются 32-битные счетчики времени.

Каждый экземпляр, который хранит время, необходимо пересмотреть, обновить все API и все инструменты, которые его используют.

Слои абстракции, которые позволяют вам устанавливать время в удобочитаемом формате времени вместо записанных необработанных данных, делают это проще, но это только один случай.

Я подозреваю, что это будет гораздо большее дело, чем думает большинство людей.

Это мое мнение, но эта проблема связана с проблемой 32-битного счетчика, сегодня большинство ОС обновлены для обработки времени на 64-битных (по крайней мере, на 64-битных компьютерах), поэтому я предполагаю, что все ОС и программное обеспечение будет готово долго время до 2038 года, скажем, до 2020 года. Таким образом, у вас могут возникнуть проблемы, только если в 2038 году вы все еще будете использовать программное обеспечение с 2020 года.
Скорее всего, это не будет проблемой почти во всех случаях. Я надеюсь.

Не такое уж большое дело.

Во время первого блиц-выпуска 2000 года, когда поставщики программного и аппаратного обеспечения должны были сертифицировать свои продукты как «совместимые с Y2K», чтобы их можно было продать (я помню, сетевые кабели на подключении к ПК были сертифицированы как совместимые с Y2K), многие компании провели подробный аудит всего , установив часы на будущее и протестировав.

В то время, когда стоимость тестирования была так высока, они почти всегда тестировались с несколькими датами, такими как 1/1/99 (некоторые разработчики могли использовать 99 в качестве часового), 31.12.99, 1/1 / 00, скачок 2000 года, 19.01.38 и многие другие. Смотрите здесь для утомительного списка.

Таким образом, я считаю, что любое важное программное обеспечение, появившееся в 1999 году, вероятно, не будет содержать ошибок 2038, но новое программное обеспечение, написанное с тех пор невежественными программистами, может. После целого фиаско Y2K программисты, как правило, стали гораздо больше осведомлены о проблемах кодирования дат, так что вряд ли это окажет такое же большое влияние, как Y2K (что само по себе было чем-то вроде антиклимакса).

32-битные системы, работающие к тому времени, будут проблемой.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

это должно быть 1 вместо 9, но ctime не обрабатывает большую дату:

8 - Sun Jun 13 07:26:08 1141709097

Моя система (конечно, 64-битная) может работать даже на 1 миллион лет больше. Решение состоит в том, чтобы обновить системы до 64 бит.

Подвох в том, что программы могут не справиться с этим. Особенно старый, свойственный и не обслуживаемый. Разработчики привыкли к следующим фактам:

• int32-битные (на самом деле они сохраняются как 32-битные в 64-битных системах среди прочих, потому что предполагалось, что они 32-битные всегда)
• Большинство типов (таких как time_t) могут быть безопасно брошены наint

В популярном программном обеспечении FLOSS обе вещи, вероятно, не пройдут через обзор «многими глазами». От менее популярного и проповеднического он будет зависеть от автора.

Я предполагаю, что в мире free * nix 2038 будет «незамеченным», в то время как я ожидаю проблем на «правильных» платформах (т. Е. С большим количеством правильного программного обеспечения) - особенно если не будет поддерживаться какая-либо важная часть.

Если это что-то вроде Y2K, то некоторые люди уже пострадали и меняют программное обеспечение, но большинство разработчиков будут игнорировать его до 2030-х годов, возможно, до 2035 года, когда будет много работы, и кто-нибудь достаточно взрослый знать K & R C и еще не слишком старческий может внезапно заключить контракт за большие деньги. Фактический переход покажет многое из того, что еще не сделано, вероятно, не так уж важно.

Проблема 2000 года заключалась в том, что вместо четырех были представлены два чартера.

Многие системы не могли отличить 2000 от 1900 года, так как они сохраняли только «00».

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

Так что давайте все будем беспокоиться о 10000 году (Y10K). За исключением писателей ОС и библиотек ...