2011-09-16 6 views
5

Sto usando la funzione mktime (struct tm *) in Suse 10.Comportamento confuso di mktime su Linux?

Ora, noto un comportamento strano quando è abilitata l'ora legale. Diciamo che ho attivato l'ora legale per iniziare il 15 settembre alle 18:10 e la correzione della luce del giorno è per 30 minuti. Ora, quando chiamo mktime con la struttura tm che ha la data come Sep 15 18:10 e tm_isdst è impostato su 0, allora torno gli stessi valori nella struttura tm solo con tm_isdst impostato su 1.

Ma, se il passaggio la data come Sep 15 18:10 con tm_isdst impostato su 1, quindi trovo il tempo è cambiato in 17:40. Questa correzione nella struttura tm viene rilevata per il tempo trascorso tra il 15 settembre 18:10 e il 15 settembre alle 18:40, ma successivamente non avviene alcuna correzione nel tempo e il flag dst rimane abilitato. Anche se passo la data come Sep 16 18:10, nessuna correzione temporale si verifica solo il flag dst rimane abilitato.

Sono totalmente confuso. È questo il comportamento corretto di mktime?

risposta

6

Se le modifiche ora locale 30 minuti per l'ora legale, poi una volta all'anno c'è 30 minuti di tempo locale che accade due volte (una volta con l'ora legale, e una volta senza) e altri 30 minuti che mai accade (viene saltato quando l'ora cambia).

Quindi i tempi locali entro 30 minuti da quando l'orologio viene arretrato sono ambigui, a meno che non sia specificato se l'ora legale è in vigore; ci sono due istanti effettivi nel tempo a cui potrebbero corrispondere.

I tempi locali entro 30 minuti da quando l'orologio viene impostato su avanti non sono validi; non ci sono istanti effettivi nel tempo a cui potrebbero corrispondere (anche se la conversione potrebbe ancora essere fatta supponendo che l'ora legale sia in vigore, o che non sia in vigore).

Quindi, per alcune ore locali (ignorando lo stato dell'ora legale) potrebbe esserci più di una volta UTC corrispondente, ma per ogni ora UTC c'è solo una possibile ora locale (se le regolazioni dell'ora legale sono contabilizzate correttamente).

Quando si chiama mktime, si sta convertendo l'ora locale in cui lo si assegna a time_t come se l'ora legale sia o meno in vigore, a seconda del valore di tm_isdst. I valori corretti che si ottengono si basano sul retro di questa conversione e il sistema determinerà se si ottiene un orario DST o un orario non-DST, a seconda della sua idea di se l'ora legale è in vigore al momento della conversione. Il tempo che hai assegnato e il tempo in cui sei tornato in realtà rappresentano lo stesso momento nel tempo, ma con offset diversi da UTC a causa dei diversi stati dell'ora legale.

Quindi sì, questo è il comportamento corretto di mktime. Si suppone che normalizzi i valori nella struttura, in base alla sua idea di come rappresentare correttamente il tempo che gli hai dato.

Questo illustra anche il motivo per cui si dovrebbe fare attenzione sull'utilizzo ora locale tenere traccia di eventi reali - se lo stato o DST offset da UTC non viene salvata insieme al tempo, alcuni valori temporali locali possono essere ambigui.

+0

Non lo so.Forse non è definito passare il tempo 18:10 (dst 0) a mktime, ma penso che la cosa più utile per tornare in quel caso sarebbe stata 18:40 (dst 1) –

0

Check out this answer e vedere se questo aiuta. Inoltre, qual è il fuso orario del sistema sfasato? Controllare da corsa:

date +%z 
+1

Grazie per la risposta. L'offset del fuso orario del sistema restituisce +0830. Ma la mia domanda è perché la correzione temporale avviene solo nel momento in cui l'ora legale viene abilitata. Ad esempio: DST è impostato per essere abilitato al 15 settembre 18:10, quindi il problema si verifica da quel momento per mezz'ora. Ma, il 16 settembre 18:10, il problema non si verifica. Perché? – Jay