La struttura FILETIME di Windows include i secondi bisestili?

StackOverflow https://stackoverflow.com/questions/130573

Domanda

La struttura FILETIME conta dal 1 ° gennaio 1601 (presumibilmente l'inizio di quel giorno) secondo la documentazione di Microsoft, ma questo include i secondi bisestili?

È stato utile?

Soluzione

La domanda non dovrebbe essere se FILETIME include i secondi bisestili.

Dovrebbe essere:

  

Le persone, le funzioni e le biblioteche che interpretano un FILETIME (ovvero FileTimeToSystemTime ) includono i secondi bisestili quando si conta la durata?

La risposta semplice è " no " . FileTimeToSystemTime restituisce i secondi come 0..59 .

La risposta più semplice è: " ovviamente no, come potrebbe? " ;.

La mia macchina Windows 2000 non sa che ci sono stati 2 secondi bisestili aggiunti nel decennio da quando è stato rilasciato. Qualsiasi interpretazione di un FILETIME è errata.

Infine, anziché fare affidamento sulla logica, possiamo determinare mediante l'osservazione sperimentale diretta la risposta alla domanda sui poster: 

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)));

Aggiungendo un secondo a 

12/31/2008 11:59:59pm

dà 

1/1/2009 12:00:00am

anziché 

1/1/2009 11:59:60pm

Q.E.D.

Il poster originale potrebbe non piacere, ma Dio l'ha intenzionalmente truccato in modo che un anno non sia uniformemente divisibile per un giorno. Lo ha fatto solo per rovinare i programmatori.

Altri suggerimenti

Qui sono disponibili ulteriori informazioni sul perché quel particolare la data è stata scelta.

  

La struttura FILETIME registra l'ora in   la forma di intervalli di 100 nanosecondi   dal 1 ° gennaio 1601. Perché era quello   data scelta?

     

Il calendario gregoriano opera su a   Ciclo di 400 anni e 1601 è il primo   anno del ciclo attivo a   al tempo di Windows NT   progettato. In altre parole, lo era   scelto per far uscire la matematica   bene.

     

In realtà ho l'e-mail di Dave   Cutler lo conferma.

Non ci può essere una sola risposta a questa domanda senza prima decidere: cosa conta effettivamente FILETIME di Windows? I documenti Microsoft affermano che conta intervalli di 100 nanosecondi dal 1601 UTC, ma questo è problematico.

Non esisteva alcuna forma di tempo coordinato a livello internazionale prima dell'anno 1960. Il nome UTC stesso non compare in nessuna letteratura precedente al 1964. Il nome UTC come designazione ufficiale non esisteva fino al 1970. Ma peggiora. Il Royal Greenwich Observatory non fu istituito fino al 1676, quindi anche tentando di interpretare il FILETIME come GMT non ha un chiaro significato, ed era solo in quel momento che gli orologi a pendolo con scappamenti accurati iniziarono a dare una precisione di 1 secondo.

Se FILETIME viene interpretato come secondi solari medi, il numero di secondi bisestili dal 1601 è zero, poiché UT non ha secondi salti. Se FILETIME viene interpretato come se ci fossero stati cronometri atomici, il numero di secondi bisestili dal 1601 è di circa -60 (ovvero 60 secondi bisestili negativi).

Questa è storia antica, che dire dell'era dai cronometri atomici? Non è meglio perché i governi nazionali non hanno fatto la distinzione tra secondi solari medi e secondi SI. Per un decennio l'ITU-R ha discusso dell'abbandono dei secondi bisestili, ma non ha raggiunto il consenso internazionale. Parte del motivo di ciò può essere visto nel javascript in questa pagina (vedere anche il collegamento delta-T in quella pagina per trame della storia antica). Poiché i governi nazionali non hanno fatto una chiara distinzione, qualsiasi tentativo di definire il conteggio dei secondi dal 1972 corre il rischio di non essere valido secondo le leggi di alcune giurisdizioni. I delegati di ITU-R sono consapevoli di questa complessità, così come lo sono i membri del comitato POSIX. Fino a quando le questioni diplomatiche non saranno risolte, fino a quando i governi nazionali e gli standard internazionali non faranno una chiara distinzione e scelta tra secondi medi solari e SI, ci sono poche speranze che gli standard informatici possano seguire l'esempio.

I secondi di salto vengono aggiunti in modo imprevedibile da IERS. 23 secondi sono stati aggiunti dal 1972, quando sono stati definiti UTC e secondi intercalari. Wikipedia dice "poiché la velocità di rotazione della Terra è imprevedibile a lungo termine, non è possibile prevederne la necessità con più di sei mesi di anticipo."

Dal momento che dovresti tenere una cronologia di quando sono stati inseriti i secondi bisestili e continuare ad aggiornare il sistema operativo per mantenere un riferimento a quando sono stati inseriti e la differenza è così piccola, è giusto non aspettarsi un generale- scopo del sistema operativo per compensare i secondi bisestili.

Inoltre, la normale deviazione dell'orologio, del semplice orologio elettronico nel tuo PC rispetto all'UTC, è molto più grande della compensazione richiesta per i secondi bisestili. Se hai bisogno del tipo di precisione per compensare i secondi bisestili, non dovresti usare l'orologio per PC altamente impreciso.

La risposta a questa domanda era no, ma è cambiata in: SÌ, in qualche modo, a volte ...

Per l'articolo del blog del team di Windows Networking :

  

A partire dal Server 2019 e dalle API del tempo di aggiornamento di Windows 10 di ottobre [2018] ora verranno prese in considerazione tutti i secondi bisestili di cui il sistema operativo è a conoscenza quando traduce FILETIME in SystemTime.

Poiché non sono stati emessi secondi di salto dal momento in cui questa funzione è stata aggiunta, il sistema operativo non è ancora a conoscenza di alcun secondo di salto. Tuttavia, quando il secondo salto ufficiale successivo si farà strada nel mondo, i computer Windows che hanno abilitato questa nuova funzionalità ne terranno traccia, e quindi i valori FILETIME saranno compensati dal numero di secondi bisestili su il computer al momento in cui vengono interpretati.

Il post sul blog continua descrivendo:

  

Non viene apportata alcuna modifica a FILETIME. Rappresenta ancora il numero di intervalli di 100 ns dall'inizio dell'epoca. Ciò che è cambiato è l'interpretazione di quel numero quando viene convertito in SYSTEMTIME e viceversa. Ecco un elenco di API interessate:

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

Prima di questa versione, SYSTEMTIME aveva valori validi per wSecond tra 0 e 59. SYSTEMTIME ora è stato aggiornato per consentire un valore di 60, a condizione che l'anno, il mese e il giorno rappresentino il giorno in cui è valido un secondo intercalare.

     

...

     

Per ricevere i 60 secondi nella struttura SYSTEMTIME un processo deve esplicitamente opt-in.

Si noti che l'adesione si applica al comportamento all'interno delle funzioni elencate su come un FILETIME viene mappato su un SYSTEMTIME . Indipendentemente dal fatto che tu abbia optato o meno, il sistema operativo eseguirà comunque la compensazione dei valori FILETIME in base ai secondi bisestili di cui è a conoscenza.

Per quanto riguarda la compatibilità, l'articolo afferma:

  

Le applicazioni che si basano su framework di terze parti dovrebbero garantire che l'implementazione del loro framework su Windows stia anche chiamando le API corrette per calcolare l'ora corretta, altrimenti l'applicazione presenterà l'ora sbagliata.

E fornisce anche collegamenti a un post precedente che descrive come disabilitare l'intera funzione, come segue:

  

... puoi ripristinare il precedente comportamento del sistema operativo e disabilitare i secondi bisestili su tutta la linea aggiungendo la seguente chiave di registro:

     
      
  • HKLM \ SYSTEM \ CurrentControlSet \ Control \ LeapSecondInformation
    •   
  • Tipo: " REG_DWORD "
    •   
  • Nome: abilitato
    •   
  • Valore: 0 disabilita l'impostazione a livello di sistema
    •   
  • Valore: 1 Abilita l'impostazione a livello di sistema
    •   
     

Successivamente, riavvia il sistema.

Un sommario molto grezzo:

UTC = (Atomic Time) + (Leap Seconds) ~~ (Mean Solar Time)

La documentazione di MS dice, in particolare, "UTC", e quindi dovrebbe includere i secondi bisestili. Come sempre con la SM, il tuo chilometraggio può variare.

Secondo questo comment windows è totalmente inconsapevole dei secondi bisestili. Se aggiungi 24 * 60 * 60 secondi a un FILETIME che rappresenta oggi 1:39:45, otterrai un FILETIME che rappresenta domani 1:39:45, non importa quale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top