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

Question

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

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

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

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

Answer 1

Почему возможно свидание с 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 00 365 с = 31536000 с. Это, конечно, только среднее значение, игнорируя високосные годы, високосные секунды или любые изменения в календаре, которые будущие постапокалиптические режимы могут диктовать оставшимся землянам.
• 9223372036854775807 ⨉ 0,0000001 с / 31536000 с ≈ 29247 лет
• @corsiKa объясняет, как мы можем вычесть високосные годы: 29247/365/4 ≈ 20
• Таким образом, ваш максимальный год составляет 1601 + 29247 - 20 = 30828.

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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