Max Home IndustryТеперь мы знаем, почему Microsoft в прошлом месяце отключила свою вычислительную службу Azure. И это действительно была самая глупая ошибка!
Если вы похожи на большинство программистов, вы не можете не хотеть знать об ошибках других людей и хихикать над тем, насколько глупыми они были. Когда мы услышали, что служба Microsoft Azure потерпела крах из — за ошибки високосного года, мы, вероятно, все почувствовали, что даты сложны, и любой из нас мог совершить такую ошибку. Итак, немного позлорадствовав и поразмыслив над ошибками в целом, мы, вероятно, занялись обычными делами.
Теперь мы можем наслаждаться всем этим снова, поскольку Microsoft подробно описывает точную природу ошибки даты — и это настолько глупо, насколько это возможно. Цитирую Билла Лэйнга из Azure:
Когда ГА создает сертификат передачи, он предоставляет ему срок действия в один год. Он использует полночь текущего дня в качестве действительной даты и один год с этой даты в качестве действительной даты. Ошибка високосного дня заключается в том, что ГА рассчитала действительную дату, просто взяв текущую дату и добавив ее к своему году. Это означало, что любой ГА, который пытался создать сертификат передачи в високосный день, установил действительную дату 29 февраля 2013 года, недопустимую дату, которая привела к сбою создания сертификата.
Понял?!
Не беспокойтесь о том, что происходит с сертификатами и т. Д., Сосредоточьтесь на важной части :
Ошибка високосного дня заключается в том, что GA рассчитала действительную дату, просто взяв текущую дату и добавив ее к своему году
Это не становится более неловким, чем это.
Чтобы быть справедливым, добавление одного к дате года в изоляции таким образом идет не так только 29 февраля, но обратите внимание, что это всегда идет не так, нет никаких других осложняющих факторов. Соответствующий программист, должно быть, совершенно не знал о високосных годах, работая над проблемой.
Единственный безопасный способ работы с датами-это преобразовать многоосновную дату в дни с доверительной точки, выполнить все необходимые арифметические действия, а затем преобразовать обратно в действительную многоосновную дату. Однако это затрудняет такие операции, как получение даты, которая составляет 1 год или 1 месяц, — что вы добавляете 365 или 366?
Интересно, что еще одна из крупных публичных ошибок Microsoft, когда Zune (музыкальный плеер, который они больше не поддерживают) упал, также была вызвана ошибкой високосного года. Загадочная часть заключается в том, что в этом случае ошибка привела к тому, что Zune стал кирпичом 31 декабря 2008 года, но о проблеме, которая вызвала это, становится легче догадаться, когда вы понимаете, что это последний день високосного года — да, это также связано с проблемой 365 или 366 дней в году.
Вы могли бы подумать, что после того, как ошибка Zune вызвала столько проблем, у Microsoft может быть действующая директива о том, что все программное обеспечение даты должно быть проверено на наличие проблем високосного года.
В случае проблемы с Azure Microsoft решила вернуть 33% за февраль, независимо от того, были ли какие-либо проблемы вызваны для клиента неработающими SSL-сертификатами. Вся надежность облачной инфраструктуры по — прежнему зависит от способности программиста создавать код без ошибок или толерантный к ошибкам-это касается не только UPSS и серверов резервного копирования.