La struttura _finddata_t restituisce time_write come ora di sistema o è influenzata dal fuso orario della sessione?

Mi riferisco alla documentazione delle _filefirst() e _findnext() qui

Queste API restituiscono le informazioni sui file in una struttura _finddata_t. Devo accedere al tempo di modifica del file dall’elemento time_write . Anche se la documentazione dice che il tempo è memorizzato in formato UTC (è un timestamp). La documentazione non chiarisce se questa volta rappresenta l’ora locale o l’ora UTC. Mi sembra che time_write non restituisca l’ora UTC, invece il suo valore è influenzato dalle impostazioni del fuso orario del sistema.

La mia domanda è: time_write restituisce l’ora locale rappresentata nei timestamp UTC?

Edit1 Qui spiego cosa effettivamente sto cercando di capire. Il mio sistema è in fuso orario IST. Ora, c’è un file emp10.ibd per quale finestra mostra

Data di creazione – 21/10/2016 10:51

Data modifica-10/21/2016 10:51

Ho usato il convertitore di epoca per scoprire il timestamp di epoca in cui risulta essere il seguente:

Ora locale per la conversione di epoca

Ora se time_write elemento time_write dalla struttura _finddata_t che è stato restituito da _findnext() per lo stesso file, ad esempio emp10.ibd . Mi aspetto che il timestamp restituito dovrebbe essere vicino

Epoch timestamp 1477027260 come mostrato nell’immagine sopra.

Ma ho il time_write come 1477043509

Se uso ancora il convertitore di epoca ottengo il seguente epoca al tempo locale

Sto cercando di capire perché ci sono 4:30 ore di differenza di orario in GMT in entrambe le immagini condivise sopra? Il timestamp IMO avrebbe dovuto essere quasi lo stesso. Che cosa ovvio mi manca qui?

Edit2 Per quelle persone che stavano chiedendo il codice di esempio. Qui ho incollato il link di un altro post che avevo chiesto un anno fa per lo stesso motivo, ma lo scenario era leggermente diverso, Lì mi riferivo alla struttura di _stati64. Non ho risolto il problema ulteriormente in quel momento. Ormai è abbastanza chiaro che le API _finddata_t e _stati64 sono influenzate dalla variabile di ambiente _tzset come Harry ha menzionato in questo post mentre la struct FILETIME non lo è.

L’ora locale è UTC più un offset geografico più potenzialmente un offset stagionale. Un timestamp UTC non ha compensazioni di questo tipo.

In questo caso particolare, il formato esatto è secondi dal 1970-01-01T00:00:00Z cioè il 1 ° gennaio 1970, a mezzanotte UTC.

Per risolvere ulteriormente il problema, ho utilizzato l’ API GetFileTime per recuperare l’ora di modifica del file nella struttura FILETIME e convertito l’ora in timestamp UTC. Ho avuto il tempo secondo il tempo impostato sul mio computer. Mi aspettavo lo stesso.

A questo punto ho iniziato a indagare sul modo in cui eseguiamo il nostro programma attraverso uno script perl. Ho trovato che lo script perl stava impostando il fuso orario su GMT-1 .
Dal momento che il mio computer era in fuso orario GMT+5:30 , quindi +04:30 hrs risultante +04:30 hrs di differenza come menzionato nel post originale.

Quindi vorrei riassumere la mia esperienza in quanto – il risultato di _finddata_t strcut è influenzato dal fuso orario impostato nella sessione ma il risultato della FILETIME struct non è influenzato dal fuso orario impostato nella sessione, invece è il tempo in base alla fuso orario del sistema. Dal momento che stavo recuperando una volta usando la FILETIME struct e un’altra usando la _finddata_t strcut che stava causando il problema. Mi ci sono voluti ~ 48 ore per scoprire questa osservazione interessante.

Perché succede? Forse la risposta è fornita da Harry nella sezione commenti. Sto incollando lo stesso qui com’è –

la modifica del fuso orario in Perl sta probabilmente causando l’impostazione della variabile di ambiente TZ, che influisce sulla libreria di runtime C come da documentazione per _tzset . Non è un’impostazione per sessione, almeno non nel modo in cui Windows utilizza la parola “sessione”. ”

Edit1

Da File Times , ho letto quanto segue:

FindFirstFile recupera l’ora locale dal file system FAT e la converte in UTC utilizzando le impostazioni correnti per il fuso orario e l’ora legale.

Sebbene stavo usando il file system NTFS, ma credo che usi lo stesso meccanismo, cioè recupera l’ora locale dal file system e la converte in UTC usando le impostazioni correnti. Questa è la ragione per cui ho notato la differenza.