Проверка систем на готовность к 2000-му году - трудоемкий и длительный процесс. Приступая к нему, важно иметь нормативную базу, критерии оценки готовности систем. В течение 1996-97 гг. различные комиссии и комитеты, образованные при правительствах ведущих стран (прежде всего США), ведущие компьютерные компании вырабатывали общие критерии для оценки способности инфомационных систем оперировать датами как XX-го, так и XXI-веков. Условно такую сопособность стали называть "совместимостью с 2000 годом" (Year 2000 date compiance, Y2K compiance ) или более точно "совместимостью c веком" (Century compliance).
Автору этой статьи пока не удалось обнаружить никаких официальных документов Правительства России, Академии наук, Госстандарта или Гос. Думы по этой проблеме. Возможно их и нет в природе. Однако, руководителям предприятий и специалистам по информационным технологиям не следует откладывать проверку своих систем до появления правительственных документов.Объем проверок беспрецедентно высок. Большинство зарубежных аналитических фирм утверждает, что те, кто приступил к тестированию лишь в начале 1988 г., а не ранее, успеет выявить и исправить не более 70% вех ошибок.
До появления отечественных критериев и нормативов целесообразно воспользоваться зарубежным опытом. Наиболее общие критерии для оценки "совместимости с веком" информационных систем разработала в 1996 г. американская Корпорация правительственных систем (Government Systems Corporation – GTE). Многие ведущие фирмы (не только компьютерные) и правительства разных стран опубликовали критерии "совместимости с веком", мало отличающиеся от критериев GTE.
Основные критерии
В большинстве официальных документов и статей выделяют 4 основных критерия "совместимости с веком".
Для всех операционных систем и всех технических платформ типовым считается временной период с 01/01/1985 по 31/12/2035. Необходимо дополнительно убедиться в правильности представления в ЭВМ ряда "критических" дат и способности компьютерного календаря правильно переключиться в полночь на следующую дату.
Как правило, к "критическим" относят следующие даты:
31/12/1998 - последний день 1998 г.;
09/09/1999 - дата, содержащая 5 девяток;
31/12/1999 - последний день столетия;
01/01/2000 - первый день нового столетия;
28/02/2000 - предпоследний день февраля;
29/02/2000 - последний день февраля (дополнительный день високосного года);
01/03/2000 - первый день после дополнительного;
31/12/2000 - последний день 2000 г.;
01/01/2001 - первый день 2001 г.
Проверяют и отработку системой ошибочных дат, например 29/02/2001.
Для программ, запускаемых периодически (раз в неделю, месяц, квартал и т.п.) проверяют специфические даты, например, 01.01.2000 – выходной в первый день месяца, 30.04.2000 – выходной в последний день месяца и т.п.
2. Целостность данных. Все манипуляции с данными, представляющими собой календарную дату (вычисление временных периодов, дней недели и т.п.) должны приводить к правильным результатам во всем диапазоне дат, на который рассчитано приложение.
Все вычисления должны быть основаны на Григорианском календаре. Как правило, программные средства должны обеспечивать манипуляции с датами, находящимися в диапазоне от 01/01/1900 до 31/12/2050 (т.е. 150 лет). Следует обратить внимание, что в этом диапазоне все годы, значение которых делится на 4, являются високосными, за исключением года 1900. В отдельных программных продуктах временной диапазон может быть сокращен (например, в программах, ориентированных на ограниченные по времени процессы, скажем деноминацию рубля) или расширен (например, в базе данных исторического архива). Во всех программах переменным типа "дата" при их инициализации должно по умолчанию присваиваться значение 00/00/0000. Не должно быть специальной интерпретации отдельных значений даты (например, "99" или "00").
3.Явное представление столетия. Элементы представления даты в пользовательском интерфейсе и внутренних форматах позволяют явно указывать столетие, исключая неоднозначное толкование даты.
Все разрабатываемые и приобретаемые программы должны позволять использование форматов даты с явным представлением столетия. Информация о столетии не должна искажаться или теряться при записи даты в память, на внешние носители или пересылке между программами и компьютерами.
Международные стандарты разрешают использовать два полных формата представления даты: YYYYMMDD (т.е., год, месяц, день) и YYYYJJJ (год и номер дня в году). Все вновь разрабатываемые программы должны использовать только явное представление столетия в соответствии с этим стандартом или другими аналогичными. Не должно быть значения столетия "по умолчанию".
В пользовательском интерфейсе возможны и другие представления (например, 28-ЯНВ-1998), однако с явным указанием столетия.
4.Неявное представление столетия. Для любого значения даты, представленного без явного указания столетия, должны быть соглашения (алгоритмы), позволяющие определять столетие недвусмысленно со 100%-ной точностью для всех операций, в которых эти значения используются.
Стандарты допускают сокращенные форматы даты YYMMDD или YYJJJ, однако руководящие и методические материалы фирм допускают в новых разработках использование сокращенных форматов лишь в пользовательских интерфейсах. Во внутреннем представлении все данные типа "дата" должны явно содержать значение столетия во всех форматах хранения или передачи данных.
Для операционных систем, языков программирования, СУБД, коммерческих прикладных программ могут создаваться специальные наборы критериев.
Типовые ошибки в прикладных программах
1. Неправильная интерпретация информации о столетии. Это наиболее часто встречающиеся ошибки в системах, использующих для представления даты 1 или 2 цифры. Их можно разделить на несколько подгрупп:
- программа воспринимает год 00 (т.е. 2000), как ошибочный. Такое явление встречается во многих старых программах, например, DBU системы Clipper, FOX-Pro для DOS и др. Впервые на такие ошибки обратили внимание в 1995 г., когда появились банковские магнитные карты со сроком окончания действия в 2000 г.
- пользовательский интерфейс не позволяет задать год с помощью 4-х цифр, а две вводимые цифры всегда воспринимаются как 19xx. Подобная ошибка характерна например, для Lotus 1-2-3, а также многих "самодельных" систем, построенных на базе пакетов Clipper, dBASE, FoxPro, Access и некоторых других, выпущенных до 1997 г.;
- неправильно выполняется сортировка по датам. Например, дата 31/12/1999 считается большей, чем 01/01/2000. Такие ошибки встречаются в программах, использующих для хранения даты собственные нестандартные форматы (например, символьный формат и порядок записи: день, месяц, год):
неправильное вычисление разности двух дат. В случае представления года двумя цифрами разность например 20/03/00 – 15/05/65 в старых системах будет равна -23797 дням (т.е., результат- отрицательное число). Подобные ошибки особенно опасны в финансовых системах. Расчеты стажа работы, оплаты за пользование ресурсами (газ, вода, свет и т.п.) окажутся невозможными;
"урезание" информации о столетии в процессе преобразования данных типа дата в прикладной программе. Например, интерфейс пользователя позволяет вводить 4 цифры даты типа 20хх, но на одном из этапов преобразования две цифры столетия урезаются, а при записи в базу данных по умолчанию добавляются цифры 19. Другой вариант подобной ошибки – в диалоговом окне для ввода даты заведомо записаны цифры 20, а пользователь добавляет лишь последние две цифры. Эти две цифры затем вводятся в программу, а при записи в базу данных добавляются цифры 19. Подобные ошибки могут быть в любом старом приложении, т.к., большинство СУБД, выпущенных до 1997 г. перед двузначными датами автоматически ставят цифры 19;
2. Сравнение двух дат, относящихся к XX и XXI столетиям выполняется так, будто обе они относятся к XX столетию. Подобные ошибки особенно опасны в системах регистрации и учета, проверяющих сроки окончания полномочий (например, доступа к серверам, базам данных или спецхранилищам). Из-за подобных ошибок многие служащие в начале 2000-го года не смогут получить доступ к нужным данным или попасть на свое рабочее место (а что будет твориться в оборонных системах?);
3. Расширенное толкование отдельных значений даты. Чаще всего в прикладных программах специальный смысл имеет число 99. Оно может трактоваться, например, как "дата не назначена" или наоборот, "срок истек" и т.п. В таких системах либо все, либо некоторые даты, относящиеся к 1999 г. не смогут быть представлены.
4. Ошибки в программных реализациях календарей. Часто в различных АРМах размещаются самодельные календари, позволяющие не вводить дату с клавиатуры, а выбирать из календаря с помощью мыши. В таких календарях может быть целый "букет" ошибок. Чаще всего не учитывается, что год 2000 високосный, т.е., в календарях не предусмотрен день 29 февраля 2000 г. Иногда, наоборот, високосным считается год 1900.
5. Переполнение поля даты. Во многих программных продуктах дата представляется в виде целого числа, означающего приращение относительно базовой даты. Приращение может быть выражено в днях, часах, минутах, секундах, а иногда, и в милисекундах. Если количество байтов, отводимых под такое число, выбрано неправильно, возможно переполнение поля даты. В одних случаях это приводит к невозможности дальнейшей работы приложения, в других – к сбросу значения приращения в 0 (т.е., возврату к базовой дате). Подобные ошибки наблюдаются с 1996 г.как в некоторых компьютерах, так и прикладных программах.
6. Противоречивое толкование значения столетия. Даты, представленные двумя цифрами, передаваемые из одной программы в другую, могут рассматриваться, как относящиеся к разным столетиям. Например, дата 25/05/20 в системах Access 1.1, 2.0 и других, выпущенных до 1997 г. будет трактоваться как 25/05/1920 а в системе Access 97 – как 25/05/2020.
Чтобы правильно спланировать работу по подготовке используемых на предприятии программ к 2000 году и уменьшить объем тестирования, целесообразно найти фирменную информацию о работе с датами систем программирования и инструментальных средств. Программистам полезно самостоятельно попытаться смоделировать перечисленные ошибки, чтобы "прочувствовать" механизмы, заложенные в программных средтсвах.
Очевидно, в системах, использующих 4-х значное представление даты, число проблем будет минимальным (необходимо лишь убедиться, что значение столетия нигде не урезается). Особенности работы с датами некоторых программных продуктов будут рассмотрены в следующем номере газеты.
Internet продолжает приносить новости о событиях в компьютерном мире, связанных с проблемой 2000 года. На многочисленных зарубежных Web-страницах, посвященных этой проблеме, ежедневно появляются названия новых фирм, предлагающих услуги по анализу компьютерных систем и устранению ошибок, связанных с обработкой даты. Странно, что пока ни одна из петербургских фирм не поместила объявление о выполнении подобных работ. В ближайшее время муниципальные, государственные и коммерческие предприятия столкнутся с реальными проблемами в своих компьютерных системах, и возникнет острая потребность в консультантах и программистах, способных решать проблемы 2000 года.
А проблемы уже начали возникать. Так, при формировании городской базы данных о студентах (для продажи им проездных карточек) обнаружилось, что юноши и девушки, поступившие в вузы в прошлом году, закончат их в …1903 г.! К счастью, это пока не повлияло на продажу им карточек. Ясно, что в вузах (включая наш родной ГЭТУ) операторы вводили вместо полной даты 2003 лишь последние две цифры: 03. А внутренние функции СУБД автоматически подставили впереди цифры 19. Вполне возможно, что дата 1903 появилась в результате ошибочного выполнения арифметических операций с датами.
Зададим себе простой вопрос: а в каких еще системах может проявиться подобная ошибка? Например, человека осудили на 5 лет. Какую дату окончания срока запомнит компьютер? Может быть тоже 1903? Ребят призвали в Армию. Какой год окончания службы значится в штабных базах данных? Вполне возможно 1900. Конечно командир взвода не поверит компьютеру и не отпустит новобранцев, как отслуживших 100 лет назад. Будем надеяться, что и надзиратель не выпустит преступника. Но вот какой-нибудь снабженец может и не предусмотреть для них довольствие и проч.
Таких вопросов много.