На сайте Microsoft Learn, где компания публикует техническую документацию и ресурсы для разработчиков, обнаружилась статья с любопытным названием: "Excel ошибочно считает, что 1900 год был високосным". Казалось бы, подобная ошибка давно должна была привести к катастрофическим последствиям, но на деле этот баг хорошо известен среди опытных пользователей Excel уже десятки лет – и Microsoft осознанно отказывается его исправлять, так как последствия исправления были бы куда хуже самой ошибки.
Когда Lotus 1-2-3 впервые вышла, программа предполагала, что 1900 год был високосным, хотя на самом деле он таковым не был. Это упрощало обработку високосных годов в программе и не причиняло вреда практически никаким вычислениям дат в Lotus 1-2-3.
Lotus 1-2-3 была, по сути, предшественницей Excel – невероятно популярная программа для работы с электронными таблицами от компании Lotus Software, которая помогла персональным компьютерам IBM доминировать на рынке деловых решений в 1980-х годах. До сих пор нет единого мнения, был ли этот баг сознательным решением программистов Lotus для экономии ценной оперативной памяти за счёт упрощения вычисления дат, или же это была обычная ошибка.
Однако Lotus 1-2-3 была настолько популярна, что Microsoft при создании собственного аналога была вынуждена расставить приоритеты в пользу совместимости. Ни один бизнес не перешёл бы на Excel, если бы все существующие таблицы оказались несовместимы с новой программой. Когда вышли Microsoft Multiplan, а затем и Microsoft Excel, обе программы приняли то же допущение, используя аналогичную систему последовательной нумерации дат, что позволяло пользователям легко импортировать рабочие листы из одного приложения в другое. Стоит отметить, что все остальные високосные годы обрабатываются корректно – проблема касается исключительно 1900 года.
Офисные продукты Microsoft обогнали решения Lotus в начале 1990-х и с тех пор доминируют на рынке, хотя продукты Lotus окончательно перестали продаваться только в 2013 году. Но "наследственный" баг с високосным годом остался. Microsoft признаёт, что "технически исправить это поведение возможно, однако недостатки такого решения перевешивают преимущества". Компания перечисляет проблемы, которые возникнут в случае исправления:
- Практически все даты в существующих документах и таблицах Excel сдвинутся на один день назад, а исправление этого сдвига потребует значительных затрат времени и усилий, особенно в формулах, использующих даты.
- Некоторые функции, например WEEKDAY, станут возвращать другие значения, что может привести к некорректной работе формул в таблицах.
- Исправление нарушит совместимость системы последовательных дат между Excel и другими программами, работающими с датами.
Масштаб потенциальной проблемы становится очевиден, если вспомнить, что Excel остаётся отраслевым стандартом деловых приложений и, по различным оценкам, насчитывает от 750 миллионов до миллиарда пользователей по всему миру. Если Microsoft решит исправить этот баг, каскадные последствия, помимо очевидных, попросту невозможно предсказать.
Как отмечает сама Microsoft, сохранение текущего поведения приводит лишь к одной проблеме:
Функция WEEKDAY возвращает некорректные значения для дат до 1 марта 1900 года. Но так как большинство пользователей не работают с датами до 1 марта 1900 года, эта проблема встречается крайне редко.
Баги, связанные с високосными годами, давно стали отдельным жанром в мире программного обеспечения, но этот случай особенно примечателен. Каким бы ни было происхождение ошибки, она давно превратилась из бага в функцию, а сегодня настолько укоренилась, что даже стандарт Open Office XML официально включает её в свои требования.
Комментарии