¿La estructura FILETIME de Windows incluye segundos intercalares?
https://stackoverflow.com/questions/130573
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
La estructura FILETIME cuenta desde el 1 de enero de 1601 (presumiblemente el comienzo de ese día) de acuerdo con la documentación de Microsoft, pero ¿esto incluye los segundos bisiestos?
Solución
La pregunta no debería ser si FILETIME incluye segundos intercalares.
Debería ser:
¿Las personas, funciones y bibliotecas que interpretan un
FILETIME(es decir,FileTimeToSystemTime) incluyen segundos bisiestos al contar la duración?
La respuesta simple es " no " . FileTimeToSystemTime devuelve segundos como 0..59 .
La respuesta más simple es: " por supuesto que no, ¿cómo podría? " ;.
Mi máquina con Windows 2000 no sabe que se agregaron 2 segundos bisiestos en la década desde su lanzamiento. Cualquier interpretación que haga de un FILETIME es incorrecta.
Finalmente, en lugar de depender de la lógica, podemos determinar mediante observación experimental directa, la respuesta a la pregunta de los pósters:
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)));
Agregar un segundo a
12/31/2008 11:59:59pm
da
1/1/2009 12:00:00am
en lugar de
1/1/2009 11:59:60pm
Q.E.D.
Puede que no le guste el póster original, pero Dios lo manipuló intencionalmente para que un año no sea divisible por un día. Lo hizo solo para fastidiar a los programadores.
Otros consejos
Aquí hay más información sobre por qué ese particular la fecha fue elegida.
La estructura FILETIME registra el tiempo en la forma de intervalos de 100 nanosegundos desde el 1 de enero de 1601. ¿Por qué fue eso? fecha elegida?
El calendario gregoriano opera en un Ciclo de 400 años, y 1601 es el primero año del ciclo que estuvo activo en el tiempo que Windows NT estaba siendo diseñado. En otras palabras, fue elegido para que salgan las matemáticas muy bien.
En realidad tengo el correo electrónico de Dave Cutler confirmando esto.
No puede haber una respuesta única a esta pregunta sin decidir primero: ¿Qué está contando realmente el FILETIME de Windows? Los documentos de Microsoft dicen que cuenta con intervalos de 100 nanosegundos desde 1601 UTC, pero esto es problemático.
No existía ninguna forma de tiempo coordinado internacionalmente antes del año 1960. El nombre UTC en sí no aparece en ninguna literatura anterior a 1964. El nombre UTC como designación oficial no existía hasta 1970. Pero empeora. El Observatorio Royal Greenwich no se estableció hasta 1676, por lo que incluso tratar de interpretar el FILETIME como GMT no tiene un significado claro, y fue solo alrededor de ese momento que los relojes de péndulo con escapes precisos comenzaron a dar una precisión de 1 segundo.
Si FILETIME se interpreta como segundos solares medios, entonces el número de segundos bisiestos desde 1601 es cero, porque UT no tiene segundos bisiestos. Si FILETIME se interpreta como si hubiera habido cronómetros atómicos, entonces el número de segundos bisiestos desde 1601 es de aproximadamente -60 (es decir, 60 segundos bisiestos negativos).
Esa es la historia antigua, ¿qué pasa con la era desde los cronómetros atómicos? No es mejor porque los gobiernos nacionales no han hecho la distinción entre segundos solares medios y segundos SI. Durante una década, el UIT-R ha estado discutiendo el abandono de los segundos bisiestos, pero no han logrado el consenso internacional. Parte de la razón de eso se puede ver en el javascript en esta página (también vea el enlace delta-T en esa página para tramas de la historia antigua). Debido a que los gobiernos nacionales no han hecho una distinción clara, cualquier intento de definir la cuenta de segundos desde 1972 corre el riesgo de ser inválido de acuerdo con las leyes de alguna jurisdicción. Los delegados al UIT-R son conscientes de esta complejidad, al igual que la gente del comité POSIX. Hasta que se resuelvan los problemas diplomáticos, hasta que los gobiernos nacionales y las normas internacionales hagan una clara distinción y elección entre la media solar y los segundos del SI, hay pocas esperanzas de que las normas informáticas puedan hacer lo mismo.
Los segundos de salto se agregan de manera impredecible por el IERS. Se han agregado 23 segundos desde 1972, cuando se definieron los UTC y los segundos bisiestos. Wikipedia dice "porque la tasa de rotación de la Tierra es impredecible a largo plazo, no es posible predecir la necesidad de ellos con más de seis meses de anticipación".
Dado que tendría que mantener un historial de cuándo se insertaron los segundos bisiestos, y seguir actualizando el sistema operativo para mantener una referencia de cuándo se habían insertado, y la diferencia es tan pequeña, es justo no esperar un general- sistema operativo para compensar los segundos bisiestos.
Además, la deriva del reloj regular, del reloj electrónico simple en su PC en comparación con UTC, es mucho mayor que la compensación requerida para los segundos bisiestos. Si necesita el tipo de precisión para compensar los segundos bisiestos, no debe usar el reloj de PC altamente inexacto.
La respuesta a esta pregunta solía ser no, pero ha cambiado a: SÍ, algo así, a veces ...
Por el artículo del blog del equipo de Windows Networking :
A partir de Server 2019 y el tiempo de actualización de Windows 10 de octubre [2018], las API ahora tendrán en cuenta todos los segundos bisiestos que el sistema operativo conoce cuando traduce FILETIME a SystemTime.
Como no se han emitido segundos bisiestos desde el momento en que se agregó esta función, el sistema operativo aún no tiene conocimiento de ningún segundo bisiesto. Sin embargo, cuando el próximo segundo salto oficial llegue al mundo, las computadoras con Windows que tengan esta nueva característica habilitada lo mantendrán al tanto y, por lo tanto, los valores de FILETIME serán compensados ??por la cantidad de segundos de salto en la computadora en el momento en que se interpretan.
La publicación del blog continúa describiendo:
No se realiza ningún cambio en FILETIME. Todavía representa el número de intervalos de 100 ns desde el comienzo de la época. Lo que ha cambiado es la interpretación de ese número cuando se convierte a SYSTEMTIME y viceversa. Aquí hay una lista de las API afectadas:
- GetSystemTime
- GetLocalTime
- FileTimeToSystemTime
- FileTimeToLocalTime
- SystemTimeToFileTime
- SetSystemTime
- SetLocalTime
Antes de esta versión, SYSTEMTIME tenía valores válidos para wSecond entre 0 y 59. SYSTEMTIME ahora se ha actualizado para permitir un valor de 60, siempre que el año, el mes y el día representen el día en que un segundo intercalar es válido.
...
Para recibir los 60 segundos en la estructura SYSTEMTIME, un proceso debe optar explícitamente.
Tenga en cuenta que la aceptación se aplica al comportamiento dentro de las funciones enumeradas sobre cómo un FILETIME se asigna a un SYSTEMTIME . Independientemente de si opta o no, el sistema operativo aún compensará los valores de FILETIME de acuerdo con los segundos bisiestos de los que tenga conocimiento.
Con respecto a la compatibilidad, el artículo establece:
Las aplicaciones que se basan en marcos de terceros deben garantizar que la implementación de su marco en Windows también está llamando a las API correctas para calcular la hora correcta, o de lo contrario la aplicación tendrá el tiempo incorrecto informado.
Y también proporciona enlaces a una publicación anterior que describe cómo deshabilitar toda la función, de la siguiente manera:
... puede volver al comportamiento anterior del sistema operativo y deshabilitar los segundos intermedios en todos los ámbitos agregando la siguiente clave de registro:
HKLM:\SYSTEM\CurrentControlSet\Control\LeapSecondInformation- Tipo: " REG_DWORD "
- Nombre: habilitado
- Valor:
0Desactiva la configuración de todo el sistema- Valor:
1Habilita la configuración de todo el sistemaA continuación, reinicie su sistema.
Un resumen muy crudo:
UTC = (Tiempo atómico) + (Segundos bisiestos) ~~ (Tiempo solar medio)
La documentación de MS dice, específicamente, "UTC", por lo que debe incluir los segundos bisiestos. Como siempre con MS, su kilometraje puede variar.
De acuerdo con este comentario windows Es totalmente inconsciente de los segundos bisiestos. Si agrega 24 * 60 * 60 segundos a un FILETIME que representa 1:39:45 hoy, obtendrá un FILETIME que representa 1:39:45 mañana, pase lo que pase.
