Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Tipi di Dato > Tipi di Data/Orario
PrecedenteTipi di dato binariTipo booleanoSuccessivo

8.5. Tipi di Data/Orario

PostgreSQL™ supporta l'insieme completo dei tipi data e ora di SQL, visualizzato nella Tabella 8.9, «Tipi data/orario». Le operazioni disponibili in questi tipi di dati sono descritte in Sezione 9.9, «Funzioni e operatori di data/orario».

Tabella 8.9. Tipi data/orario

NomeDimensioneDescrizioneValore minimoValore massimoRisoluzione
timestamp [ (p) ] [ without time zone ]8 bytesia data che orario (senza fuso orario)4713 AC294276 DC1 microsecondo / 14 cifre
timestamp [ (p) ] with time zone8 bytesia data che orario, con fuso orario4713 AC294276 DC1 microsecondo / 14 cifre
date4 bytedata (senza orario del giorno)4713 AC5874897 DC1 giorno
time [ (p) ] [ without time zone ]8 byteorario del giorno (senza data)00:00:0024:00:001 microsecondo / 14 cifre
time [ (p) ] with time zone12 bytesolo orario del giorno, con fuso orario00:00:00+145924:00:00-14591 microsecondo / 14 cifre
interval [ fields ] [ (p) ]12 byteintervallo di tempo-178000000 anni178000000 anni1 microsecondo / 14 cifre

[Nota]

Nota

Lo standard SQL considera che timestamp da solo sia equivalente a timestamp without time zone (timestamp senza fuso orario), e PostgreSQL™ segue lo stesso comportamento. (Le versioni di PostgreSQL™ precedenti la 7.3, tarttavano i timestamp come timestamp with time zone (timestamp con fuso orario).)

I tipi time, timestamp, e interval accettano un valore opzionale di precisione p, il quale specifica il numero di cifre decimali restituite nel campo dei secondi. Per impostazione predefinita, non c'è alcun vincolo esplicito di precisione. L'estensione consentita per p è da 0 a 6 cifre per i tipi timestamp e interval.

[Nota]

Nota

Quando valori timestamp sono memorizzati come interi a otto byte (attualmente per default), la precizione al microsecondo è disponibile per tutta la gamma di valori. Quando invece i valori timestamp sono memorizzati come numeri a vorgola mobile con doppia precisione, (un'opzione di compilazione deprecata), il limite effettivo di precisione potrebbe essere minore di 6. I valori timestamp sono memorizzati come secondi prima o dopo la mezzanotte del 01/01/2000. Quando i valori timestamp sono implementati usando numeri a virgola mobile, la precisione al millisecondo è disponibile per date entro pochi anni dal 01/01/2000, ma la precisione degrada per date più lontane. Notare che l'uso di datetimes a virgola mobile permette un una gamma maggiore di valori rispetto a quanto mostrato sopra: da 4713 AC fino a 5874897 DC.

La stessa opzione di compilazione determina se i valori time e interval sono memorizzati come numeri a virgola mobile o interi a otto byte. Nel caso della virgola mobile, valori di grandi intervalli degradano in precisione man mano che la dimensione dell'intervallo cresce.

Per i tipi time, il valore consentito per p va da 0 a 6 se si utilizza la memorizzazione con intero a otto byte, o da 0 a 10 quando si utilizza la memorizzazione in virgola mobile.

Il tipo interval ha un'opzione aggiuntiva, che è di restringere l'insieme dei campi memorizzati scrivendo una di queste frasi:

YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
YEAR TO MONTH
DAY TO HOUR
DAY TO MINUTE
DAY TO SECOND
HOUR TO MINUTE
HOUR TO SECOND
MINUTE TO SECOND

Notare che se sono specificate sia fields che p, l'opzione fields deve includere SECOND, dato che la precisione si applica solo sui secondi.

Il tipo time with time zone è definito dallo standard SQL, ma la definizione espone proprietà che portano ad un utilizzo discutibile. Nella maggior parte dei casi, una combinazione di date, time, timestamp without time zone e timestamp with time zone dovrebbe fornire una completa gamma di funzionalità per data/ora richiesta da qualsiasi applicazione.

I tipi abstime e reltime sono tipi a bassa precisione che sono usati internamente. Siete sconsigliati dall'utilizzare questi tipi nelle applicazioni. Questi tipi interni potrebbero sparire nei rilasci futuri.

8.5.1. Input di date/orari

L'input per le date e le ore è accettato in qualsiasi plausibile formato, compreso il formato ISO 8601, SQL-compatibile, i formati tradizionali POSTGRES™, ed altri. Per alcuni formati, il posizionamento per mese, giorno e anno nelle date in input è ambiguo ed esiste un supporto per specificare il posizionamento desiderato per questi campi . Impostare il parametro DateStyle a MDY per selezionare la disposizione mese-giorno-anno, DMY per selezionare la disposizione giorno-mese-anno, YMD per selezionare la disposizione anno-mese-giorno.

PostgreSQL™ è più flessibile nella gestione dell'input di data/ora rispetto a quanto richiesto dallo standard SQL. Vedere Appendice B, Supporto di data e orario per conoscere le regole esatte di conversione dell'input di data/ora e per i campi di testo riconosciuti compresi mesi, giorni della settimana, e fusi orari.

Ricordare che ogni data o orario letterale in ingresso deve essere racchiuso tra singoli apici, come le stringhe di testo. Vedere Sezione 4.1.2.7, «Costanti di altri tipi» per ulteriori informazioni. SQL richiede la seguente sintassi

type [ (p) ] 'value'

dove la specifica di precisione opzionale p è un intero corrispondente al numero delle cifre decimali nel campo dei secondi. La precisione può essere specificata per i tipi time, timestamp e interval. I valori consentiti sono stati specificati sopra. Se non viene specificata nessuna costante di precisione, come precisione viene assunta quella propria del valore letterale.

8.5.1.1. Date

La Tabella 8.10, «Input per le date» mostra alcuni possibili valori di input per il tipo date.

Tabella 8.10. Input per le date

EsempioDescrizione
1999-01-08ISO 8601; 8 Gennaio in qualsiasi modo (formato raccomandato)
January 8, 1999non ambiguo per qualsiasi modo di input impostato con datestyle
1/8/19998 Gennaio nel modo MDY; 1 Agosto nel modo DMY
1/18/199918 Gennaio nel modo MDY; respinto negli altri modi
01/02/032 Gennaio 2003 nel modo MDY; 1 Febbraio 2003 nel modo DMY; 3 Febbraio 2001 nel modo YMD
1999-Jan-088 Gennaio in qualsiasi modo
Jan-08-19998 Gennaio in qualsiasi modo
08-Jan-19998 Gennaio in qualsiasi modo
99-Jan-088 Gennaio nel modo YMD, altrimenti errore
08-Jan-998 Gennaio, errore se in modo YMD
Jan-08-998 Gennaio, errore se in modo YMD
19990108ISO 8601; 8 Gennaio 1999 in qualsiasi modo
990108ISO 8601; 8 Gennaio 1999 in qualsiasi modo
1999.008anno e giorno dell'anno
J2451187giorno giuliano
January 8, 99 BCanno 99 AC

8.5.1.2. Orari

I tipi relativi alle ore del giorno sono time [ (p) ] without time zone e time [ (p) ] with time zone. Scrivere solo time equivale a scrivere time without time zone.

Input validi per questi tipi consistono in un ora del giorno seguita da un opzionale fuso orario. (Vedere la Tabella 8.11, «Input per gli orari» e la Tabella 8.12, «Input di fuso orario»). Se viene specificato il fuso orario nell'input di time without time zone, questo viene tranquillamente ignorato. Anche se viene specificata una data, questa sarà ignorata, eccetto se viene utilizzato un nome di fuso orario che coinvolge un utilizzo di ora estiva, come America/New_York. In questo caso è necessario specificare la data per determinare se si deve applicare l'ora standard o quella estiva. L'offset appropriato per il fuso orario è registrato nel valore time with time zone.

Tabella 8.11. Input per gli orari

EsempioDescrizione
04:05:06.789ISO 8601
04:05:06ISO 8601
04:05ISO 8601
040506ISO 8601
04:05 AMstesso di 04:05; AM non influisce sul valore
04:05 PMstesso di 16:05; l'ora di ingresso deve essere <= 12
04:05:06.789-8ISO 8601
04:05:06-08:00ISO 8601
04:05-08:00ISO 8601
040506-08ISO 8601
04:05:06 PSTfuso orario specificato con un'abbreviazione
2003-04-12 04:05:06 America/New_Yorkfuso orario specificato con il nome completo

Tabella 8.12. Input di fuso orario

EsempioDescrizione
PSTAbbreviazione (per Pacific Standard Time)
America/New_YorkNome compelto del fuso orario
PST8PDTSpecifica del fuso orario in stile POSIX
-8:00ISO-8601 scostamento da PST
-800ISO-8601 scostamento da PST
-8ISO-8601 scostamento da PST
zuluAbbreviazione militare per UTC
zForma contratta di zulu

Riferirsi a Sezione 8.5.3, «Fusi OrarioTime Zones» per maggiori informazioni su come specificare il fuso orario.

8.5.1.3. Input per i timestamp

Input validi per i tipi timestamp consistono in una concatenazione di una data e un'orario, seguiti da un opzionale fuso orario e da un opzionale AD o BC. (Alternativamente, AD/BC può apparire prima del fuso orario, ma questo non è l'ordine preferito). Per cui:

1999-01-08 04:05:06

e:

1999-01-08 04:05:06 -8:00

sono valori validi, che seguono lo standard ISO 8601. In aggiunta, il formato largamente diffuso:

January 8 04:05:06 1999 PST

è supportato.

Lo standard SQL differenzia i letterali timestamp without time zone e timestamp with time zone per la presenza di un «+» o «-» e lo scostamento di fuso orario. Per cui, secondo lo standard,

TIMESTAMP '2004-10-19 10:23:54'

è un timestamp without time zone, mentre

TIMESTAMP '2004-10-19 10:23:54+02'

è un a timestamp with time zone. PostgreSQL™ non esamina mai il contenuto di una stinga letterale prima di determinare il relativo tipo, e quindi tratterà entrambi i tipi visti sopra come timestamp without time zone. Per assicurarsi che un letterale venga trattato come timestamp with time zone, bisogna fornirgli il corretto tipo esplicito:

TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'

In un lettarale, che è stato determinato essere timestamp without time zone, PostgreSQL™ ignorerà tranquillamente qualsiasi indicazione di fuso orario. Cioè, il valore risultante deriverà dal valore in input dei campi data/ora, e non verrà adattato al fuso orario.

Per timestamp with time zone, il valore memorizzato internamente è sempre in UTC (Universal Coordinated Time, tradizionalmente conosciuto come Greenwich Mean Time, GMT). Un valore in input che ha un esplicito fuso orario specificato viene convertito in UTC utilizzando lo scostamento specifico per quel fuso orario. Se nella stringa in input non è stato indicato il fuso orario si suppone che il fuso orario sia quello indicato nel parametro di sistema timezone, e quindi viene convertita in UTC utilizzando lo scostamento per il fuso timezone.

Quando in uscita si ha un valore timestamp with time zone, questo viene sempre convertito da UTC al corrente fuso timezone, e visualizzato come ora locale in quel fuso. Per visualizzare l'ora in un altro fuso orario, modificare timezone o usare il costrutto AT TIME ZONE (vedere dentro Sezione 9.9.3, «AT TIME ZONE»).

Le conversioni tra timestamp without time zone e timestamp with time zone assumono normalmente che il valore timestamp without time zone verrà accettato o fornito come ora locale timezone. Un diverso riferimento di fuso può essere specificato per la conversione utilizzando AT TIME ZONE.

8.5.1.4. Valori speciali

PostgreSQL™ supporta in input, per comodità, diversi valori speciali di data/ora, come mostrato nella Tabella 8.13, «Input speciali di data/ora». I valori infinity e -infinity sono rappresentazioni speciali all'interno del sistema e possono essere visualizzati nel modo normale; ma gli altri sono semplici notazioni abbreviate che verranno convertite in valori data/ora ordinari quando letti. (In particolare, now e le relative stringhe vengono convertite in uno specifici valori di orario al momento appena vengono lette). Tutti questi valori devono essere scritti racchiusi tra singoli apici quando vengono usati come costanti in comandi SQL.

Tabella 8.13. Input speciali di data/ora

Stringa in inputTipi validiDescrizione
epochdate, timestamp1970-01-01 00:00:00+00 (Tempo zero di sistema UNIX)
infinitydate, timestampsuccessivo a tutti gli altri time stamps
-infinitydate, timestampprecedente a tutti gli altri time stamps
nowdate, time, timestampmomento di avvio della transazione corrente
todaydate, timestampmezzanotte di oggi
tomorrowdate, timestampmezzanotte di domani
yesterdaydate, timestampmezzanotte di ieri
allballstime00:00:00.00 UTC

Le seguenti funzioni compatibili SQL possono anche essere utilizzate per ottenere l'attuale valore temporale per il corrispondente tipo di dato: CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. Le ultime quattro accettano la specificazione opzionale di precisione dei subsecondi. (Vedere Sezione 9.9.4, «Data/orario corrente».) Notare uttavia che queste sono funzioni SQL e non sono riconosciute come stringhe per input dati.

8.5.2. Ouput di data/ora

Il formato di output dei tipi data/ora può essere impostato a uno dei quattro stili ISO 8601, SQL (Ingres), POSTGRES tradizionale e German, utilizzando il comando SET datestyle. Il formato predefinito è l'ISO. (Lo standard SQL richiede l'uso del formato ISO 8601. Il nome del formato di output «SQL» è un incidente storico). La Tabella 8.14, «Stili di output per data/ora» mostra esempi di ogni stile di output. L'output dei tipi date e time è naturalmente solo la parte data o ora in conformità con l'esempio fornito.

Tabella 8.14. Stili di output per data/ora

Specifica stileDescrizioneEsempio
ISOISO 8601/SQL standard1997-12-17 07:37:16-08
SQLstile tradizionale12/17/1997 07:37:16.00 PST
POSTGRESstile originaleWed Dec 17 07:37:16 1997 PST
Germanstile regionale17.12.1997 07:37:16.00 PST

Negli stili SQL e POSTGRES, se è stato specificato il campo di ordinamento DMY, i giorni compaiono prima dei mesi, altrimenti i mesi compaiono prima dei giorni. (Vedere Sezione 8.5.1, «Input di date/orari» per come questa impostazione influisce nell'interpretazione dei valori in input). La Tabella 8.15, «Convenzioni di ordinamento della data» mostra un esempio.

Tabella 8.15. Convenzioni di ordinamento della data

Impostazione datestyleOrdinamento in inputEsempio di output
SQL, DMYgiorno/mese/anno17/12/1997 15:37:16.00 CET
SQL, MDYmese/giorno/anno12/17/1997 07:37:16.00 PST
Postgres, DMYgiorno/mese/annoWed 17 Dec 07:37:16 1997 PST

Gli stili di data/ora, possono essere selezionati dall'utente usando il comando SET datestyle, il parametro DateStyle nel file di configurazione postgresql.conf, o la variabile di ambiente PGDATESTYLE nel server o nel client. Per formattare l'output di data/ora in un modo più flessibile, è anche disponibile la funzione to_char (Vedere Sezione 9.8, «Funzioni di formattazione dei tipi di dato»).

8.5.3. Fusi OrarioTime Zones

I fusi orari e le convenzioni per i fusi orari, sono influenzati da decisioni politiche, non solo dalla geometria della terra. I fusi orari intorno al mondo cominciano ad essere standardizzati durante il 1900, ma continuano ad essere soggetti a modifiche arbitrarie, particolarmente rispetto alle regole per l'ora estiva. PostgreSQL™ sfrutta il database di fusi orari zoneinfo per informazioni sulle regole storiche riguardanti i fusi orario. Per orari, nel futuro, si assume che l'ultima regola per un dato fuso orario continui ad essere osservata indefinitamente nel futuro.

PostgreSQL™ si sforza di essere compatibile con le definizioni dello standard SQL per usi tipici. Tuttavia, lo standard SQL ha uno strano miscuglio di tipi e di possibilità per data e ora. Due problemi evidenti sono:

  • Anche se il tipo date non ha un fuso orario associato, il tipo time potrebbe averlo. I fusi orari nel mondo reale hanno uno scarso significato a meno che non siano associati ad una data oltre che ad un ora, poichè lo scostamento può variare durante l'anno, in funzione dell'applicazione dell'ora estiva.

  • Il fuso orario predefinito è specificato come una costante numerica di scostamento da UTC. Non è perciò possibile adattarlo all'ora estiva quando l'aritmetica data/ora viene fatta attraverso i confini del DST.

Per far fronte a queste difficoltà, si raccomanda di utilizzare tipi data/ora che contengano ambedue le informazioni di data e ora quando si utilizzano i fusi orari. Si raccomanda di non utilizzare il tipo time with time zone (Anche se è supportato da PostgreSQL™ per le applicazioni ereditate e per conformità con lo standard SQL). PostgreSQL™ presume che il fuso orario locale per qualsiasi tipo contenga solo data o ora.

Tutte le date e ore consapevoli del fuso orario sono memorizzate internamente in UTC. Esse vengono convertite in ora locale nel fuso specificato dal parametro di configurazione timezone prima di essere visualizate al client.

PostgreSQL™ consente di specificare il fuso orario in tre modi differenti:

  • Un nome completo di fuso orario, per esempio America/New_York. I nomi riconosciuti di fusi orario sono elencati nella vista pg_timezone_names (vedere Sezione 45.60, «pg_timezone_names»). PostgreSQL™ utilizza per questo scopo i dati di fusi orari zic ampiamente usati, in modo che gli stessi nomi siano riconosciuti anche da molti altri software.

  • Una abbreviazione di fuso orario, per esempio PST. Tale specifica si limita a definire un particolare scostamento da UTC, in contrasto con il nome completo di fuso orario il quale potrebbe implicare un insieme di regole di transizioni delle date per l'ora estiva. Le abbreviazioni riconosciute sono elencate nella vista pg_timezone_abbrevs (vedere Sezione 45.59, «pg_timezone_abbrevs»). Non si possono impostare i parametri di configurazione timezone o log_timezone utilizzando un'abbrevizione di fuso orario, ma si possono usare le abbreviazioni nei valori di input data/ora e con l'operatore AT TIME ZONE.

  • Oltre ai nomi di fusi orari e alla abbreviazioni, PostgreSQL™ accetterà anche specificazioni di fuso orario stile POSIX nella forma STDscostamento o STDscostamentoDST, dove STD è una abbreviazione di fuso, scostamento è uno scostamento numerico in ore a sinistra da UTC, e DST è un opzionale abbreviazione di "zona di ora estiva", presupponendo di stare un'ora avanti dallo scostamento fornito. Per esempio, se EST5EDT non è un nome riconosciuto di fuso orario, esso sarà accettato e sarà funzionalmente equivalente all'ora della costa est degli USA. Quando è presente un nome di fuso di ora legale, si presuppone che sarà usato con le stesse regole di transizione all'ora estiva usate nelle voci posixrule del database di fusi orari zic. In una installazione PostgreSQL™ standard, posixrules è identico a US/Eastern, così che le specificazioni di fusi orari in stile POSIX seguono le regole dell'ora estiva USA. Se necessario, è possibile modificare questo comportamento sostituendo il file posixrules.

In breve, c'è una differenza concettuale e pratica tra le abbreviazioni e i nomi completi: le abbreviazioni rappresentano sempre uno scostamento fisso dall'UTC, mentre la maggior parte dei nomi completi implica una regola di gestione dell'ora estiva locale per cui si hanno due possibili scostamenti UTC.

Bisogna stare attenti che lo stile POSIX di fuso orario può portare ad accettare passivamente input fasullo, dato che non c'è alcun controllo sulla logicità delle abbreviazioni di fuso. Per esempio, SET TIMEZONE TO FOOBAR0 funzionerà, lasciando che il sistema usi effettivamente un'abbreviazione piuttosto strana per UTC. Un altra questione da tenere a mente è che nei nomi di fusi orari POSIX, vengono usati scostamenti positivi per locazioni ad ovest di Greenwich. In qualsiasi altro luogo, PostgreSQL™ segue la convenzione ISO-8601 che gli scostamenti positivi del fuso orario sono ad est di Greenwich.

In ogni casi, i nomi di fusi orari sono riconosciuti insensibili alle maiuscole. (Ciò è diverso dalle versioni di PostgreSQL™ precedenti alla 8.2, dove c'era distinzione tra le maiuscole e le minuscole in alcuni contesti e non in altri).

Nè i nomi completi nè le abbreviazioni sono incorporati nel server; essi vengono ottenuti dai file di configurazione memorizzati sotto .../share/timezone/ e .../share/timezonesets/ della directory di installazione (vedere Sezione B.3, «File di configurazione di data e orario»).

Il parametro di configurazione timezone può essere impostato nel file postgresql.conf, o in qualcuno degli altri modi standard descritti nel Capitolo 18, Configurazione del server. Ci sono anche altri modi speciali per impostarlo:

  • Se timezone non è specificato nè in postgresql.conf e neanche come una opzione a linea di comando per il server, il server prova ad utilizzare il valore della variabile di ambiente TZ come fuso orario predefinito. Se TZ non è definito o non è uno dei nomi di fusi orari conosciuti da PostgreSQL™, il server tenta di determinare il fuso orario predefinito del sistema verificando il comportamento della funzione della libreria C localtime(). Il fuso orario predefinito viene selezionato come la corrispondenza più vicina ai fusi orari conosciuti da PostgreSQL™. (Queste regole vengono anche utilizzate per scegliere il valore predefinito di log_timezone, se non è stato specificato).

  • Il comando SQL SET TIME ZONE imposta il fuso orario per la sessione. Questa è una versione alternativa di SET TIMEZONE TO con una sintassi più compatibile alle specifiche SQL.

  • La variabile di ambiente PGTZ è utilizzata dai client libpq per inviare un comando SET TIME ZONE al server al momento della connessione.

8.5.4. Input di Intervalli

I valori interval possono essere scritti usando la seguente sintassi:

[@] quantity unit [quantity unit...] [direction]

Dove: quantità è un numero (possibilmente con segno); unità è microsecondo, millisecondo, secondo, minuto, ora, giorno, settimana, mese, anno, decennio, secolo, millennio, o abbreviazioni o plurali di queste unità; direzione può essere ago o vuoto. Il simbolo at (@) è un opzionale. Le quantità delle diverse unità vengono implicitamente sommate con la appropriata registrazione del segno. ago nega tutti i campi. Questa sintassi è usata anche per l'output di intervalli, se IntervalStyle è impostata a postgres_verbose.

Le quantità di giorni, ore, minuti e secondi possono essere specificate senza una esplicita marcatura delle unità. Per esempio, '1 12:59:10' viene letto nella stessa modo di '1 day 12 hours 59 min 10 sec'. Inoltre, una combinazione di anni e mesi può essere specificata con un trattino; Per esempio, '200-10' verrà letto come '200 anni 10 mesi'. (Queste forme contratte sono infatti le sole permesse dallo standard SQL, e sono usate per l'output quando IntervalStyle è impostato a sql_standard.)

Valori di intervallo possono anche essere scritti come intervalli di tempo ISO 8601,

[Nota]

Nota

Nota per il revisore: designator? - testo originale: Interval values can also be written as ISO 8601 time intervals, using either the «format with designators» of the standard's section 4.4.3.2 or the «alternative format» of section 4.4.3.3.

usando sia il «formato con designator» della sezione 4.4.3.2 dello standard, o il «formato alternativo» della sezione 4.4.3.3. Il formato con designator si esprime così:

P quantity unit [ quantity unit ...] [ T [ quantity unit ...]]

La stringa deve iniziare con una P, e può includere una T che introduce le unità orario-del-giorno. Le abbreviazioni di unità disponibili sono presenti in Tabella 8.16, «Abbreviazioni delle unità di intervallo ISO 8601». Le unità potrebbero essere omesse, e potrebbero essere specificate in qualsiasi ordine, ma unità più piccole di un giorno devono apparire dopo T. In particolare, il significato di M dipende dal fatto che sia prima o dopo la T.

Tabella 8.16. Abbreviazioni delle unità di intervallo ISO 8601

AbbreviationeSignificato
YAnni
MMesi (nella parte data)
WSettimane
DGiorni
HOre
MMinute (nella parte orario)
SSecondi

Nei formati alternativi:

P [ years-months-days ] [ T hours:minutes:seconds ]

la stringa deve iniziare con P, e una T separa le parti di data e ora dell'intervallo. I valori sono dati come numeri simili alle date ISO 8601.

Quando si scrive un intervallo costante con la specificazione di campi, o quando si assegna una stringa a una colonna di intervallo che è stata definita con una specificazione di campi, l'interpretazione di quantità senza segno dipende dai campi. Per esempio INTERVAL '1' YEAR è letto come 1 anno, dal momento che INTERVAL '1' significa 1 secondo. Inoltre, valori di campo «alla destra» del campo meno significativo permesso dalla specifica dei campi sono scartati automaticamente. Per esempio, scrivere INTERVAL '1 day 2:03:04' HOUR TO MINUTE elimina il secondo campo, ma non il campo "day" (giorno).

In accordo allo standard SQL tutti i campi di un valore di intervallo devono avere lo stesso segno, così un segno meno in cima si applica a tutti i campi; per esempio, il segno negativo nell'intervallo letterale '-1 2:03:04' si applica sia alla parte dei giorni che alla parte ore/minuti/secondi. PostgreSQL™ permette ai campi di avere segno differente, e tradizionalmente tratta ogni campo nella rappresentazione testuale come avente segno indipendente, così la parte ore/minuti/secondi è considerata positiva in questo esempio. Se IntervalStyle è impostato a sql_standard allora il segno principale è considerato da applicare a tutti i campi (ma solo se non appaiono segni aggiuntivi). Altrimentii viene usata l'interpretazione tradizionale PostgreSQL™. Per evitare ambiguità, è raccomandato aggiungere un segno esplicito ad ogni campo se qualcuno è negativo.

Internamente i valori interval sono immagazzinati come mesi, giorni e secondi. Viene fatto questo perchè il numero di giorni in un mese varia, e un giorno puà avere 23 o 25 ore se è coinvolto un cambiamento di orario. I campi mesi e giorni sono interi mentre il campo secondi può avere frazioni. Dato che gli intervalli sono solitamente creati da stringhe costanti o sottrazioni di timestamp, questo metodo di immagazzinamento lavora bene in molti casi. Sono disponibili le funzioni justify_days e justify_hours per aggiustare giorni e ore che superano i loro normali range.

Nel formato di input prolisso, ed in alcuni campi dei formati di input più compatti, i valori dei campi possono avere parti frazionali; per esempio '1.5 week' o '01:02:03.45'. Questi valori di input sono convertiti nell'appropriato numero di mesi, giorni, e secondi per l'immagazzinamento. Quando questo risulterebbe in un numero frazionale di mesi o giorni, la frazione è aggiunta ai campi di ordine più basso usando i fattori di conversione 1 mese = 30 giorni e 1 giorno = 24 ore. Per esempio, '1.5 month' diventa 1 mese e 15 giorni. Solo i secondi saranno sempre mostrati come frazionali in output.

Tabella 8.17, «Input di intervalli» mostra alcuni esempi di input validi di intervallo.

Tabella 8.17. Input di intervalli

EsempioDescrizione
1-2formato SQL standard: 1 anno 2 mesi
3 4:05:06formato SQL standard: 3 giorni 4 ore 5 minuti 6 secondi
1 year 2 months 3 days 4 hours 5 minutes 6 secondsFormato tradizionale di Postgres: 1 anno 2 mesi 3 giorni 4 ore 5 minuti 6 secondi
P1Y2M3DT4H5M6SISO 8601 «formato con designators»: stesso significato di sopra
P0001-02-03T04:05:06ISO 8601 «formato alternativo»: stesso significato di sopra

8.5.5. Output di intervalli

Il formato di output del tipo intervallo puà essere impostato ad uno dei quattro stili sql_standard, postgres, postgres_verbose, o iso_8601, usando il comando SET intervalstyle. postgres è il formato di default. Tabella 8.18, «Esempi di stile di output per gli intervalli» mostra esempi di ogni stile di output.

Lo stile sql_standard produce output conforme alle specifiche dello standard SQL per stringhe letterali di intervalli, se il valore di intervallo rispetta le restrizioni dello standard (sia solo anno-mese o solo giorno-ora, senza componenti miste negative e positive). Altrimenti l'output sarà una stringa letterale anno-mese seguita da una stringa letterale giorno-ora, con segni espliciti aggiunti per rendere non ambigui intervalli con segni misti.

L'output dello stile postgres corrisponde all'output dello stile delle versioni precedenti la 8.4 di PostgreSQL™, quando il parametro DateStyle era impostato a ISO.

L'output dello stile postgres_verbose corrisponde all'output dello stile delle versioni precedenti la 8.4 di PostgreSQL™, quando il parametro DateStyle era impostato a non-ISO.

L'output dello stile iso_8601 corrisponde al «formato con designator» descritto nella sezione 4.4.3.2 dello standard ISO 8601.

Tabella 8.18. Esempi di stile di output per gli intervalli

Specifice di stileIntervallo anno-meseIntervallo giorno-oraIntervallo misto
sql_standard1-23 4:05:06-1-2 +3 -4:05:06
postgres1 year 2 mons3 days 04:05:06-1 year -2 mons +3 days -04:05:06
postgres_verbose@ 1 year 2 mons@ 3 days 4 hours 5 mins 6 secs@ 1 year 2 mons -3 days 4 hours 5 mins 6 secs ago
iso_8601P1Y2MP3DT4H5M6SP-1Y-2M3DT-4H-5M-6S

8.5.6. Internals

[Nota]

Nota

Nota per il revisore: Internals?

PostgreSQL™ utilizza le date Giuliane per tutti i calcoli data/ora. Esse hanno la buona proprietà di calcolare correttamente ogni data più recente del 4713 AC e lontana nel futuro, usando l'assunzione che la lunghezza dell'anno è di 365,2425 giorni.

La convenzioni per le date precedenti al 19° secolo servono per una interessante lettura, ma non sono abbastanza consistenti da garantire la codificazione in un gestore di data/ora.

Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Tipi di Dato > Tipi di Data/Orario
PrecedenteTipi di dato binariTipo booleanoSuccessivo