Как файл может быть «создан» в 1641 году?

Несколько лет назад я наткнулся на этот файл на нашем файловом сервере.

И мне интересно, как файл может сказать, что он был создан в 1641 году? Насколько я знаю, время на ПК определяется числом секунд с 1 января 1970 года. Если этот индекс не работает, вы можете получить 31 декабря 1969 года (индекс, вероятно, говорит -1), но я озадачен этим на первый взгляд случайная дата, предшествующая даже основанию Соединенных Штатов Америки.

Так как же можно датировать файл 1641 годом?

PS: даты на французском. Февраль февраль.

Почему возможно свидание 1600-х годов?

Windows не хранит метки времени изменения файлов, как в системах Unix . По данным Windows Dev Center (выделено мое):

Время файла - это 64-разрядное значение, представляющее число интервалов в 100 наносекунд , прошедших с 12:00 1 января 1601 года. Всемирное координированное время (UTC). Система записывает время файлов, когда приложения создают, получают доступ и записывают в файлы.

Таким образом, установив неправильное значение здесь, вы можете легко получить даты 1600-х годов.

Конечно, еще один важный вопрос: как было установлено это значение? Какая фактическая дата? Я думаю, вы никогда не сможете это выяснить, поскольку это могло быть просто ошибкой вычисления в драйвере файловой системы. Другой ответ предполагает, что дата на самом деле является меткой времени Unix, интерпретируемой как метка времени Windows, но на самом деле они рассчитываются на разных интервалах (секунды по сравнению с наносекундами).

Как это связано с проблемой 2038 года?

Использование 64-битного типа данных означает, что Windows (как правило) не подвержена проблеме 2038 года, которая существует в традиционных системах Unix, поскольку Unix изначально использовала 32-битное целое число, которое переполняется раньше, чем 64-битное целое число, которое Windows есть. (Это несмотря на то, что Unix работает за секунды, а Windows - за микро / наносекунды.)

Конечно, Windows по-прежнему подвержена влиянию 32-битных программ, скомпилированных со старыми версиями Visual Studio.

Более новые операционные системы Unix уже расширили тип данных до 64 бит, что позволило избежать этой проблемы. (Фактически, поскольку временные метки Unix работают в секундах, новая дата оборота будет через 292 миллиарда лет.)

Какую максимальную дату можно установить?

Для любопытных - вот как это вычислить:

• Число возможных значений в 64-битовое целое число в 2 ⁶³ - 1 = 9223372036854775807 .
• Каждый тик представляет 100 наносекунд, что составляет 0,1 мкс или 0,0000001 с.
• Максимальный диапазон времени будет 9223372036854775807 ⨉ 0,0000001 с , то есть сотни миллиардов секунд.
• Один час имеет 3600 секунд, один день имеет 86400 секунд, а один год имеет 365 дней, поэтому в году 86400 × 365 с = 31536000 с . Это, конечно, только среднее значение, игнорируя високосные годы, високосные секунды или любые изменения в календаре, которые будущие постапокалиптические режимы могут диктовать оставшимся землянам.
• 9223372036854775807 ⨉ 0,0000001 с / 31536000 с ≈ 29247 лет
• @corsiKaобъясняет, как мы можем вычесть високосные годы: 29247/365/4 ≈ 20
• Таким образом, ваш максимальный год составляет 1601 + 29247 - 20 = 30828 .

Некоторые люди действительно пытались установить это и придумали тот же год.

Если вы не слишком расстроились из-за некоторых догадок, позвольте мне предложить объяснение. И я не имею в виду «кто-то установил значение ерунды», это всегда возможно :)

Время Unix обычно использует количество секунд с 1970 года. Windows, с другой стороны, использует 1601 в качестве начального года. Поэтому, если мы предположим (и это большое предположение!), Что проблема заключается в неправильном преобразовании между этими двумя временами, мы можем представить, что дата, которая должна была быть представлена, фактически когда-то в 2011 году (1970 + 41), которая была неправильно преобразована до 1640 (1601 + 41) . РЕДАКТИРОВАТЬ: На самом деле, я сделал ошибку в Windows, начиная с года. Вполне возможно, что фактическое время создания было в 2010 году, или произошла другая ошибка (отдельные ошибки часто встречаются в программном обеспечении: D).

Учитывая, что в этом году произошла еще одна из дат отслеживания, связанных с данным файлом, я думаю, что это довольно правдоподобное объяснение :)

Как было написано другими, эпоха Windows в 1601-01-01 00:00 .

Количество секунд между этой эпохой и отображаемым временем файла составляет 1,266,705,294 .
Если мы добавим это к эпохе Unix, мы прибудем в субботу, 2010-02-20 23:34:54 CEST . Это примерно за год до последней даты доступа, что делает его несколько правдоподобным. Так что, возможно, это была временная метка Unix, интерпретируемая против неправильной эпохи.

Как обычно для таких вопросов, в блоге Рэймонда Чена есть ответ на этот вопрос из «Почему эпоха Win32 1 января 1601 года?» запись от 6 марта 2009 года:

FILETIMEСтруктура записывает время в виде 100-наносекундных интервалов с 1 января 1601. Почему эта дата выбрана?

Григорианский календарь работает по 400-летнему циклу, и 1601 год - это первый год цикла, который был активен во время разработки Windows NT. Другими словами, это было выбрано для того, чтобы математика получилась красивой.

На самом деле у меня есть электронное письмо от Дейва Катлера, подтверждающее это.