Мифы о проблеме-2000


Миф №-1 — миф о проблеме високосного 2000 года

Многие Y2K-программы делают большие заявки относительно испытания различных состояний високосного года. Это — полный бред: RTC имеет совершенно хороший механизм високосного года, в котором никогда не было найдено дефектов. Так как RTC не следит за столетием, не существует никакой вероятности появления проблемы в 2000 году. Испытание обработки високосного года в новом столетии имеет не больше смысла, чем проверка перехода суток в полночь, или перехода времени между 2:25 и 2:46… Столетие не имеет никакого отношения к этому.

Паникеры (aka ламеры) и торговцы тестовыми программами выдвинули идею, что есть отличие 2000 года от других високосных лет. Но что тут отличающегося? Этот год не отличается от любого другого обычного делящегося на 4 високосного года.

Обычно каждый год, который делится на 4 — високосный год, КРОМЕ лет столетий (делящихся на 100)… Но считается високосным год, делящийся на 400, что и имеет место быть в случае с 2000 годом. Так что 2000 год — обычный високосный год.

Причина для правила возвращения каждого 400-го года к високосному соответствует первоначальной причине появления високосных лет: компенсировать факт, что фактический астрономический год не точно равен 365 дням. Правило деления на 4, которое используют в старом Юлианском календаре (приписываемом Julius Caesar), полагает, что год равен 365.25 дням, и таким образом прибавляет один дополнительный день каждые 4 года. Но в действительности истинный год немного короче, ближе к 365.2422 дням. Так если использовать только правило деления на 4, то через каждые 400 лет календарная дата будет перед солнечным годом: (365.2500 — 365.2422) * 400 = 3.12 дней.

Григорианский календарь (приписанный Римскому папе Gregory XIII), который мы используем сегодня, устраняет 3 високосных года из каждых 4 столетий, так что накопленная ошибка сокращена до 0.12 дня каждые 400 лет.

Обратите внимание, что год 2100 не делится на 400, так что он не будет високосным. Это — первый год, который RTC не сможет автоматически правильно обработать. Так как дата файла DOS не может быть больше 2107, проблему «2100» не стоит учитывать… Даже если вы — очень оптимистично настроенный хранитель компьютерного музея! 🙂

Миф №-2 — эффект «time dilation» Crouch-Echlin’a

Этот таинственный эффект впервые наблюдал историк Jace Crouch, а позднее подтвердил программист Mike Echlin. Они утверждают, что после 2000 года некоторые часы реального времени и/или BIOSы могут начать выдавать случайные даты во время начальной загрузки.

Хотя этот «эффект» имеет некоторую славу в Internet, независимая проверка доказала иллюзорность этой ошибки, несмотря на исчерпывающие усилия Intel. Intel ни разу не смогла повторить это явление, даже на системе, которую предоставил Echlin, и на которой, по его словам, происходила ошибка. Однако, анализ Intel в результате испытаний раскрыл некоторые проблемы в тестовом коде Ечлина. Код должным образом не отключал системные прерывания в некоторых критических точках, что, возможно, и вызвало ошибочные результаты испытаний.

Конечно, некоторые умники будут рады продать вам «решение» этой «проблемы» в виде нового компьютера, но, скорее всего, лучший способ предотвратить эффект «time dilation» Crouch-Echlin’a — выбросить тестовый код Ечлина!

Впрочем, есть еще одна возможная причина проявления подобной ошибки. Заключается она… в севшей батарейке! В той, которая на старых моделях матерей впаяна и выглядит как бочонок, или вставлена в специальное гнездо и выглядит, как двухрублевая монетка. Решение просто — замените ее.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Проверка на спам: вставьте пропущенную цифру * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.