Беседы о программировании
В ноябре прошлого года я предупреждал о том, что у нас осталось примерно 1000 рабочих дней для решения проблемы конца 1900-х годов. Сегодня у меня есть новости, хорошие и плохие.
На роль хорошей новости я подобрал вот что: у нас все еще остается около 800 рабочих дней до понедельника, 3 января 2000 года. Плохая же новость заключается в том, что наши проблемы с датами проявятся как минимум на год раньше этого срока.
Например, недавно я получил по электронной почте сообщение о том, что в мэйнфрейме некой компании 9.9.99 является "магической" датой, по которой все массивы данных выведены из работы. Наступление (или указание) этой даты эквивалентно пометке "никогда это не удалять". Автор сообщения задавался вопросом, какие еще странности могут произойти в последний год перед "тремя нулями".
Я уже собрал длинный список анекдотов, один другого забавнее. Код года "99" ставят, чтобы обозначить "год неизвестен", "повторяется ежегодно" и еще во множестве произвольных смыслов.
Так что нам не обязательно ждать "Y2K", как стали называть 2000 год, чтобы насладиться плодами столкновения со всеобщим хаосом. Мы можем начать азартную карточную игру с нашими информационными системами на целый год раньше.
Отвлекшись от подобных "джокерных" дат, заметим, что изрядное количество программ и данных построены на базе шестисимвольных полей данных для дат в формате YYMMDD. Вряд ли это была хорошая идея, но это был закон или, по крайней мере, правило, если вы работали в федеральном правительстве или имели дело с федеральными учреждениями (а кто его не имел?).
С 1970 г. этот формат определен Федеральным стандартом обработки информации. Логично предположить, что некто, взявший на себя труд установить правила в этой области, должен был бы заглянуть чуть-чуть вперед: уж если гора родила мышь, то эта мышь, во всяком случае, должна иметь четыре лапки и хвост?
Одно из решений проблемы шестисимвольных дат - это скользящее окошко столетия. Например, можно принять, что с 1996 г. значение года из двух цифр, меньшее, чем 62, относится к 21-му веку, и ежегодно увеличивать это пороговое значение.
Однако этот способ не срабатывает в таких областях, как здравоохранение, поскольку столетние долгожители перестали быть редкостью. Некоторые сотрудники отделов ИС в здравоохранении уже сообщали о проблемах с их приложениями, которые не были рассчитаны на обработку данных о пациентах старше 99 лет.
Даже если в программах все цифры на месте, может возникнуть путаница с високосными годами. Повторим-ка все хором: "2000-й - первый високосный год на рубеже веков со дня введения григорианского календаря". Некоторые программисты кое-что об этом слышали, и этого оказалось как раз достаточно для новой опасности: они думали, что в 2000 году (как в 1900) будет только 365 дней.
Было бы, наверно, еще хуже, если бы наступающий вековой рубеж не подпадал под 400-летнее исключение: вероятно, во множестве программ записан код, прибавляющий 29-й день в каждом четвертом феврале без учета правила лет, оканчивающихся двумя нулями. Но эта логика не подведет хотя бы до 2100 года.
Растущий архив сообщений от компаний, бьющихся над решением этой проблемы, можно найти по адресу: http://www.year2000.com. Этот узел имеет ссылки на другие узлы, поддерживаемые компаниями, борющимися с этой уникальной всеобъемлющей угрозой точности и надежности наших данных.
Предупреждаю: исправлять ситуацию заранее - ужасно дорого, но пустить это дело на самотек, "чтобы сберечь деньги", может оказаться смертельно ошибочной экономией. 800; 799; 798...
Питер Kоффи
С Питером Коффи можно связаться через MCI Mail по адресу: 357-1756, через CompuServe по адресу: 72631,113 или по 3571756@mcimail.com.
