Не стоит надеяться, что в 2000 году все трудности с датами останутся позади

Eсли не будет изобретен единый стандарт представления дат в ПО, то связанные с ними проблемы будут преследовать нас и после 2000 года

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

Проблема 2038 года

Различные разновидности Unix, первая из которых родилась в недрах корпорации AT&T в конце 60-х, изначально совместимы с 2000 годом благодаря методу представления времени, использованному создателями данной операционной системы. Unix хранит даты в виде количества секунд, прошедших с 1 января 1970 года по так называемому всемирному координированному времени (Universal Coordinated Time — UTC). Эта начальная дата именуется «эпохой» (Epoch). В языке программирования Си, на котором написано множество приложений, тоже используется этот метод представления дат.

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

Из-за этого в большинстве существующих Unix-систем возможен сбой 19 января 2038 года в 3:14:08 по UTC. В этот момент дата в приложениях будет установлена как 1 января 1970 года или 13 декабря 1901 года в зависимости от того, как они были написаны. Самые старые Unix-системы дадут сбой даже раньше, в июне 2004 года.

В современных Unix-системах для хранения времени используется 32-разрядный тип данных. Причем первый разряд резервируется для знака числа, а для представления самого числа остается всего 31 разряд. Таким образом, используемый в Unix метод представления дат позволяет создать временной диапазон размером в 68 лет, конец которого приходится на 2038 год. Отрицательные значения используются для представления дат с 1901 по 1970 год.

Сбой Unix-систем — очень серьезная опасность. Под управлением Unix работает программное обеспечение Internet и большинство критически важных военных, финансовых и управленческих систем. В качестве временной меры предлагалось использовать для отсчета времени все 32 разряда — таким образом временное окно можно было бы увеличить до 136 лет. Подобное решение вполне подходит для некоторых приложений, но оно сделает невозможным обработку дат до 1970 года, что в большинстве случаев неприемлемо.

К счастью, существует более удачное решение, которое не потребует больших усилий от программистов. Если вместо 32-разрядного поля для подсчета секунд использовать 64-разрядное, то временной диапазон вырастет сразу до 584 млрд. лет. Это решение можно применить уже сейчас с помощью существующих технологий, предотвратив таким образом трудности, аналогичные ошибке 2000 года. К 2038 же году 64-разрядные системы будут использоваться повсеместно, так что вряд ли эта проблема сможет создать реальную угрозу стабильности Unix-приложений.

Временные окна

Самый популярный метод устранения ошибок, связанных с 2000 годом, — «временные окна» (windowing). Его суть состоит в создании логического «окна» размером в 100 лет, которое используется для корректной интерпретации двузначных полей года.

Методика очень простая. Компьютеру необходимо всего лишь сравнивать значения поля года с некоторым заданным заранее числом, скажем, с 40. Если значение поля меньше, значит, год больше или равен 2000. В противном случае год считается меньшим 2000. Число, с которым сравнивается поле года, называется граничной датой (pivot value).

Эта методика будет нормально работать до тех пор, пока пользователю не потребуется ввести год 2040-й и более, а в некоторых приложениях граничная дата менее 40. Например, в Microsoft Excel 95 нельзя ввести двузначным числом год больше 2019-го. Для решения этой проблемы можно было бы реализовать возможность вводить значения года как двузначным, так и четырехзначным числом, предусмотрев функцию автоматической корректной интерпретации даты.

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

Еще одна серьезная проблема, связанная с методом временных окон, возникает, когда две или более программ пытаются обмениваться информацией, содержащей двузначные поля лет. Если в этих программах используются разные граничные даты, то число 30, например, может в одной из них интерпретироваться как 1930 год, а в другой — как 2030. Положение усугубляется тем, что пользователи зачастую не имеют возможности изменить граничную дату, и она остается такой, какую задал производитель, — 50, 40, 30, 20 или даже 19!

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