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

Вопрос не должен быть, если 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

Q.E.D.

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

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

До 1960 года не существовало формы международного координированного времени. Само название UTC не встречается ни в одной литературе до 1964 года. Название UTC как официальное обозначение не существовало до 1970 года. Но ситуация становится еще хуже. Королевская Гринвичская обсерватория не была основана до 1676 года, поэтому даже попытка интерпретировать FILETIME как GMT не имеет четкого смысла, и только примерно в это время маятниковые часы с точным спусковым механизмом начали давать точность в 1 секунду.

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

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

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

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

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

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

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

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

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

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

Согласно статья в блоге команды Windows Networking:

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

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

Сообщение в блоге продолжает описывать:

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

• GetSystemTime
• GetLocalTime
• Файлтиметосистемтиме
• Файлтиметолокалтиме
• Системтиметофилетиме
• SetSystemTime
• Сетлокалтайм

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

...

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

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

Что касается совместимости, в статье говорится:

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

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

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

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

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

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

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

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

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