Включает ли структура Windows FILETIME дополнительные секунды?

Question

Структура FILETIME отсчитывается с 1 января 1601 года (предположительно с начала этого дня) согласно документации Microsoft, но включает ли это дополнительные секунды?

Answer 1

Вопрос не должен быть, если FILETIME включает високосные секунды.

Должно быть:

Включают ли люди, функции и библиотеки, которые интерпретируют FILETIME (т.е. FileTimeToSystemTime), дополнительные секунды при подсчете длительности?

Простой ответ: "нет" . FileTimeToSystemTime возвращает секунды как 0..59.

---

Более простой ответ: " конечно нет, как это могло быть? ".

Мой компьютер с Windows 2000 не знает, что за десять лет с момента его выпуска было добавлено 2 дополнительных секунды. Любая интерпретация FILETIME неверна.

---

Наконец, вместо непосредственного экспериментального наблюдения мы можем определить ответ на вопрос постеров:

var
    systemTime: TSystemTime;
    fileTime: TFileTime;
begin
    //Construct a system-time for the 12/31/2008 11:59:59 pm
    ZeroMemory(@systemTime, SizeOf(systemTime));
    systemtime.wYear := 2008;
    systemTime.wMonth := 12;
    systemTime.wDay := 31;
    systemTime.wHour := 23;
    systemtime.wMinute := 59;
    systemtime.wSecond := 59;

    //Convert it to a file time
    SystemTimeToFileTime(systemTime, {var}fileTime);

    //There was a leap second 12/31/2008 11:59:60 pm
    //Add one second to our filetime to reach the leap second
    filetime.dwLowDateTime := fileTime.dwLowDateTime+10000000; //10,000,000 * 100ns = 1s

    //Convert the filetime, sitting on a leap second, to a displayable system time
    FileTimeToSystemTime(fileTime, {var}systemTime);

    //And now print the system time
    ShowMessage(DateTimeToStr(SystemTimeToDateTime(systemTime)));

Добавление одной секунды к

12/31/2008 11:59:59pm

дает

1/1/2009 12:00:00am

вместо

1/1/2009 11:59:60pm

1039 * что и требовалось доказать *

Оригинальному постеру это может не понравиться, но Бог намеренно сфальсифицировал его так, чтобы год не делился на день поровну. Он сделал это просто, чтобы испортить программистов.

Answer 2

Здесь еще немного информации о том, почему именно эта дата была выбрана.

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

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

У меня действительно есть электронное письмо от Дейва Катлер это подтверждает.

Answer 3

Не может быть однозначного ответа на этот вопрос без предварительного решения: что на самом деле учитывает Windows FILETIME? Документы Microsoft говорят, что с 1601 UTC он считает интервалы в 100 наносекунд, но это проблематично.

Никакой формы скоординированного на международном уровне времени не существовало до 1960 года. Само название UTC не встречается ни в одной литературе до 1964 года. Официальное обозначение UTC не существовало до 1970 года. Но оно ухудшается. Королевская Гринвичская обсерватория не была создана до 1676 года, поэтому даже попытка истолковать ФИЛЬТРОМ не имеет четкого значения по Гринвичу, и только в это время маятниковые часы с точными спусками стали давать точность в 1 секунду.

Если FILETIME интерпретируется как среднее количество солнечных секунд, то количество високосных секунд с 1601 равно нулю, поскольку UT не имеет високосных секунд. Если FILETIME интерпретируется так, как если бы были атомные хронометры, то число високосных секунд с 1601 года составляет около -60 (это отрицательные 60 високосных секунд).

Это древняя история, а как насчет эпохи со времен атомных хронометров? Это не лучше, потому что национальные правительства не делали различий между средними солнечными секундами и секундами СИ. В течение десятилетия МСЭ-R обсуждал вопрос об отказе от високосных секунд, но они не достигли международного консенсуса. Часть причины этого можно увидеть в javascript на этой странице (см. Также ссылку delta-T на этой странице, где приведены сюжеты древней истории). Поскольку национальные правительства не проводят четкого разграничения, любая попытка определить количество секунд с 1972 года может быть недействительной в соответствии с законодательством какой-либо юрисдикции. Делегаты МСЭ-R знают об этой сложности, как и члены комитета POSIX. До тех пор, пока дипломатические вопросы не будут проработаны, пока национальные правительства и международные стандарты не проведут четкое различие и выбор между средними значениями солнечной и СИ секунд, мало надежды на то, что компьютерные стандарты могут последовать их примеру.

Answer 4

Дополнительные секунды непредсказуемо добавляются IERS. 23 секунды были добавлены с 1972 года, когда были определены UTC и дополнительные секунды. Википедия говорит, что «поскольку скорость вращения Земли в долгосрочной перспективе непредсказуема, невозможно предсказать потребность в них более чем за шесть месяцев».

Поскольку вам придется вести историю о том, когда были добавлены високосные секунды, и постоянно обновлять ОС, чтобы сохранить ссылку на то, когда они были вставлены, а разница настолько мала, справедливо ожидать Назначение ОС для компенсации високосных секунд.

Кроме того, обычное отклонение тактовых частот простых электронных часов в вашем ПК по сравнению с UTC намного больше, чем компенсация, необходимая для високосных секунд. Если вам нужна такая точность, чтобы компенсировать високосные секунды, вам не следует использовать крайне неточные часы ПК.

Answer 5

Ответ на этот вопрос раньше был нет, но изменился на: ДА, вроде как, иногда ...

За статья блога команды разработчиков сетей Windows :

Начиная с Server 2019 и API обновления Windows 10 октября [2018], теперь будут учитываться все дополнительные секунды, которые операционная система знает, когда она переводит FILETIME в SystemTime.

Поскольку с момента добавления этой функции не было выпущено дополнительных секунд, операционная система по-прежнему не знает о каких-либо дополнительных секундах. Однако, когда следующая официальная високосная секунда пробивается в мир, компьютеры Windows, на которых включена эта новая функция, будут отслеживать ее, и, таким образом, значения FILETIME будут смещены на количество високосных секунд на компьютере в данный момент. они интерпретируются.

В блоге описывается:

Никаких изменений в FILETIME не производится. Он по-прежнему представляет число интервалов в 100 нс с начала эпохи. Что изменилось, так это интерпретация этого числа, когда оно конвертируется в SYSTEMTIME и обратно. Вот список уязвимых API:

• GetSystemTime
• GetLocalTime
• FileTimeToSystemTime
• FileTimeToLocalTime
• SystemTimeToFileTime
• SetSystemTime
• SetLocalTime

До этого выпуска у SYSTEMTIME были допустимые значения wSecond в диапазоне от 0 до 59. Теперь SYSTEMTIME обновлено и теперь позволяет использовать значение 60, при условии, что год, месяц и день представляют день, в течение которого допустима дополнительная секунда. 1037 *

...

Чтобы получить 60 секунд в структуре SYSTEMTIME, процесс должен явно подписаться.

Обратите внимание, что согласие применяется к поведению в функциях, перечисленных на том, как FILETIME отображается на SYSTEMTIME. Независимо от того, подписаны вы или нет, операционная система по-прежнему будет компенсировать значения FILETIME в соответствии с дополнительными секундами, которые она знает.

В отношении совместимости в статье говорится:

Приложения, которые полагаются на сторонние фреймворки, должны убедиться, что реализация их фреймворка в Windows также вызывает правильные API для вычисления правильного времени, иначе приложение сообщит о неверном времени.

А также предоставляет ссылки на более раннюю запись , в которой описано, как отключить всю функцию, следующим образом:

... вы можете вернуться к предыдущему поведению операционной системы и отключить дополнительные секунды, добавив следующий раздел реестра:

• HKLM:\SYSTEM\CurrentControlSet\Control\LeapSecondInformation
• Тип: "REG_DWORD"
• Имя: включено
• Значение: 0 Отключает общесистемную настройку
• Значение: 1 Включает общесистемную настройку

Далее перезагрузите систему.

Answer 6

Согласно этому комментарию windows совершенно не знает о високосных секундах. Если вы добавите 24 * 60 * 60 секунд к FILETIME, который представляет 1:39:45 сегодня, вы получите FILETIME, который представляет 1:39:45 завтра, несмотря ни на что.

Answer 7

Очень грубое резюме:

UTC = (атомное время) + (високосные секунды) ~~ (среднее солнечное время)

В документации MS указано, в частности, «UTC», и поэтому она должна включать дополнительные секунды. Как всегда с MS, ваш пробег может отличаться.