2012-04-30 2 views
5

Stiamo implementando i nostri misuratori di flusso (molto simile a questo indicatore USGS: http://waterdata.usgs.gov/usa/nwis/uv?site_no=03539600) in modo che noi canoisti sappiano se c'è abbastanza acqua per riempire il flusso e non perdere tempo e gas da guidare là fuori. Speriamo di installarne alcuni in tutta la regione sud-est del whitewater che si estende lungo i fusi orari orientali e centrali.Fuso orario con PostgreSQL

Sto memorizzando il tempo in cui un record viene inserito utilizzando il valore predefinito di current_time per il record. Mi piacerebbe in seguito visualizzare i dati utilizzando il formato MM/DD/YYYY HH12:MI AM TZ, che emette le letture come 03/12/2012 01:00 AM CDT. Mi piacerebbe anche che l'output fosse a conoscenza dei cambiamenti nel tempo di risparmio della luce diurna, quindi l'ultima parte della frase precedente cambierebbe tra CST e CDT quando "salteremo avanti" e "ricadremmo". Questo cambiamento si è verificato il 3/11/2012 quest'anno e ho incluso le date su entrambi i lati di questa riga di ora legale. Sto usando il mio laptop Windows 7 per lo sviluppo e successivamente lo distribuiremo su una scatola Unix. Apparentemente Postgres ha rilevato che il mio computer Windows è impostato sul fuso orario degli Stati Uniti orientali. Sto provando questo con un campo "timestamp senza fuso orario" e un campo "timestamp con fuso orario" ma non riesco a farlo funzionare.

Ho provato a utilizzare "al fuso orario" nei miei contatti e ogni cosa funziona finché non è ora di visualizzare il fuso orario. L'ora effettiva fa parte della marca temporale è sottratta correttamente da un'ora quando chiedo l'ora in CDT. Ma EDT è visualizzato nell'output.

SELECT reading_time as raw, 
     reading_time at time zone 'CDT', 
     to_char(reading_time at time zone 'CDT', 
      'MM/DD/YYYY HH12:MI AM TZ') as formatted_time 
    FROM readings2; 

"2012-04-29 17:59:35.65";"2012-04-29 18:59:35.65-04";"04/29/2012 06:59 PM EDT" 
"2012-04-29 17:59:40.19";"2012-04-29 18:59:40.19-04";"04/29/2012 06:59 PM EDT" 
"2012-03-10 00:00:00";"2012-03-10 00:00:00-05";"03/10/2012 12:00 AM EST" 
"2012-03-11 00:00:00";"2012-03-11 00:00:00-05";"03/11/2012 12:00 AM EST" 
"2012-03-12 00:00:00";"2012-03-12 01:00:00-04";"03/12/2012 01:00 AM EDT" 

Sto memorizzando il fuso orario in cui ciascuno dei nostri indicatori si trova in un campo di caratteri diversi in una tabella separata. Ho preso in considerazione l'aggiunta di questo valore alla fine dell'output del tempo, ma voglio che cambi da CST a CDT senza il mio intervento.

Grazie per il vostro aiuto.

+1

Sarebbe utile se fosse possibile pubblicare l'output di 'psql''s' \ d readings2' qui. – vyegorov

risposta

15

Invece di utilizzare nomi di fuso orario come CDT o CST, è possibile considerare l'utilizzo di full Olsen-style time zone names. Nel caso dell'ora centrale, puoi scegliere un fuso orario. Uno che corrisponde alla posizione, ad esempio America/Chicago o solo US/Central. Ciò garantisce che PostgreSQL utilizzi il database tz di Olsen per determinare automaticamente se l'ora legale si applica in qualsiasi data specifica.

5

Si desidera sicuramente una colonna TIMESTAMP WITH TIME ZONE (che è anche nota come timestamptz in PostgreSQL). Ciò memorizzerà il timestamp in UTC, in modo che rappresenti un momento particolare nel tempo. Contrariamente a ciò che suggerisce il nome, lo fa non salva un fuso orario nella colonna: puoi visualizzare il timestamp recuperato nel fuso orario di tua scelta con la frase AT TIME ZONE.

La semantica di TIMESTAMP WITHOUT TIME ZONE è confusa e quasi inutile. Consiglio vivamente di non usare quel tipo affatto per quello che stai descrivendo.

Sono davvero confuso dalla parte della domanda che parla della memorizzazione del timestamp in una colonna CHARACTER VARYING. Sembra che potrebbe essere parte del problema. Se è possibile memorizzarlo in timestamptz sin dall'inizio, ho il sospetto che si avranno meno problemi. Escludendo, sarebbe più sicuro usare la notazione -04 per l'offset da UTC; ma sembra più un lavoro per me senza alcun beneficio.

+1

Per aggiungere una risposta, qui un link che tratta di questo approfondimento: http://phili.pe/posts/timestamps-and-time-zones-in-postgresql/ – jgburet