Решения Microsoft 2000   Продукты  |   Поддержка  |   Поиск  |   Путеводитель по серверу  
microsoft
  Платформа 2001   |   Digital Dashboard - Русские компоненты   |
Основная страница

Введение

Методология

Технологии

Продукты

Решения

Где и как приобрести продукты Microsoft

Где и как обучиться по продуктам Microsoft

Где и как получить техническую поддержку и консультации


Что такое "Проблема 2000 года"?

Сами названия - "проблема 2000 года", "Проблема 2000" (Year 2000 Problem, Y2K), "ошибка тысячелетия" (millennium bug) - недостаточно полно отражают суть вопроса, хотя большая часть ошибок программного обеспечения, характерных для этой проблемы, действительно начала проявляться в 2000 году. Наиболее адекватным определением "Проблемы 2000" является следующее:

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

Итак, проблема 2000 года включает в себя целый комплекс проблем, связанных с хранением и обработкой дат в вычислительных системах. К основным причинам возникновения ошибок при обработке дат можно отнести следующее.

Хранение и обработка двузначных дат. Попробуйте ответить на вопрос: "Какому году соответствует дата 01/01/01?". Правильным ответом будет: …, 1901, 2001, 2101-му и т.д. Мы привыкли использовать двузначное обозначение и практически никогда не ошибаемся, восстанавливая оставшиеся две цифры года исходя из контекста, в котором употребляется та или иная дата. В приложениях с двузначным представлением дат предполагается, что все даты относятся к текущему столетию. Поэтому в них дата 01/01/01 интерпретируется как 01/01/1901, даже если пользователь трактует ее как 01/01/2001. Очевидно, что при выполнении операций над датами, относящимися к следующему столетию, в таких приложениях будут возникать ошибки. Например, 2000 - 1999 = 1, а 00 - 99 = -99 (или 99, если отрицательные числа в приложении считаются недопустимыми).

Неверное определение високосного года. Алгоритм определения високосного года предельно прост - год является високосным, если он делится на четыре без остатка, но есть два исключительных случая: если год делится на 100, то он не високосный, а если делится на 400 - то является. К сожалению, в некоторых вычислительных системах 2000 год не распознается как високосный, а, следовательно, дата 29 февраля 2000 года для них недопустима. Неверное определение високосного года может быть вызвано как ошибочной (неполной) реализацией приведенного алгоритма, так и использованием двузначных дат (в последнем случае проверить делимость года на 400 просто не представляется возможным).

Использование специальных значений дат. Многие устаревшие приложения используют в полях дат специальные значения (чаще всего 9/9/99 или 10/10/00), указывающие на то, что данные требуют специальной обработки. Например, специальное значение даты может означать, что данные следует "хранить вечно" или что их необходимо автоматически удалить через определенный срок. Такой подход применялся с целью повышения эффективности выполнения приложений, а также для экономии памяти. При этом предполагалось, что данные, не требующие специальной обработки, никогда не будут иметь в поле даты специальное значение. В результате компании могут столкнуться с тем, что приложения, использующие специальные значения дат, могут вызвать ошибки при обработке информации.

Истоки проблемы

По своей сути проблема 2000 года не нова. Примерно такая же ситуация сложилась в конце 60-х годов, когда многие приложения в целях экономии памяти использовали для хранения даты только одну цифру года. Тогда эта проблема была решена довольно легко, поскольку существовало не так много приложений, и к тому же они являлись скорее вспомогательными инструментами, чем основными.

В настоящее время такая забота о минимизации используемой памяти может показаться неоправданной. Однако на заре развития вычислительных систем оперативная память и устройства хранения данных были очень дорогостоящими, и введение двузначного формата и специальных значений для дат считалось вполне приемлемым решением. Никто не предполагал, что приложения и алгоритмы, созданные в 70-х, будут использоваться через 30 лет. В результате неверный расчет жизненного цикла программного обеспечения привел к возникновению столь острой проблемы.

К решению проблемы, заложенной еще в начале 70-х годов, можно было приступить уже давно. Для этого были созданы все предпосылки, поскольку стоимость устройств хранения информации быстро падала, а приложения претерпевали неизбежную модификацию (в целях переноса на более современные платформы, устранения найденных ошибок и т. п.). Однако большей частью изменения, вносимые в унаследованные системы, были косметическими. Тому есть две причины:

  • во-первых, все больше возрастала роль вычислительных систем в производственном процессе (а это означает, что модифицировать их желательно как можно реже);
  • во-вторых, работал распространенный среди ряда программистов принцип: "Если это работает, то лучше не трогай".

Безусловно, изложенные выше причины возникновения проблемы 2000 года не являются единственными, ведь даже некоторые современные приложения некорректно оперируют датами, относящимися к 2000 и последующим годам. В большинстве случаев это вызвано ошибками, внесенными на этапе разработки приложения. Высокая сложность современных приложений не позволяет в краткие сроки провести полномасштабное тестирование, которое могло бы выявить все ошибки. Поэтому скрытые ошибки часто выявляются уже на этапе эксплуатации приложения.

Наконец, следует упомянуть и еще об одной причине: пользователи привыкли работать с двузначными датами, Так как они более естественны, их быстрее вводить и т. д. В принципе разрешить ввод двузначных сокращений для дат несложно, нужно только определить, каким образом приложение будет преобразовывать их в четырехзначные (т. е. как оно будет определять, к какому веку относится та или иная двузначная дата). Однако, поскольку разные приложения могут руководствоваться разными критериями, этот метод чреват ошибками при обмене данными между приложениями.

Опасность недооценки проблемы 2000 года

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

  • многие считают, что современные приложения не содержат ошибок, связанных с обработкой дат;
  • к потенциально уязвимым относят только старые приложения, написанные на языке COBOL, либо мэйнфреймы;
  • весьма распространено мнение: "Проблема 2000 года ко мне не относится";
  • часто думают, что проблема 2000 года проста для понимания, значит, решить ее тоже просто.

Проблема 2000 года затрагивает все вычислительные системы без исключения. Безусловно, мэйнфреймы и устаревшие приложения являются наиболее уязвимыми, но это не означает, что современные рабочие станции, операционные системы и приложения свободны от ошибок, связанных с обработкой дат. Приведем лишь несколько доводов в пользу этого утверждения.

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

Что касается сложности решения проблемы 2000 года, необходимо принимать во внимание следующее:

  • во-первых, в настоящее время бесперебойная работа вычислительных систем является важнейшим условием деятельности многих организаций. Недопустимой считается не только остановка, но и кратковременная пауза в работе вычислительной системы, поскольку она может привести к огромным убыткам. Поэтому решение проблемы 2000 года в таких организациях требует использования специальных, а иногда даже уникальных подходов.
  • во-вторых, современные вычислительные системы состоят из множества компонентов, которые должны работать в тесной взаимосвязи, поэтому только на полное тестирование может уйти несколько месяцев, а ведь в случае выявления ошибок их нужно еще и исправить.
назад наверх дальше


© 2000 Корпорация Microsoft. Все права защищены.

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