Types Date/Time
PostgreSQL supporte l'ensemble complet des types date et time du SQL.
Table 10. Types Date/Time
| Type | Description | Stockage | Au plus tôt | Au plus tard | Résolution |
|---|---|---|---|---|---|
| timestamp [ (p) ] without time zone | both date and time | 8 bytes | 4713 BC | AD 1465001 | 1 microsecond / 14 digits |
| timestamp [ (p) ] [ with time zone ] | both date and time | 8 bytes | 4713 BC | AD 1465001 | 1 microsecond / 14 digits |
| interval [ (p) ] | for time intervals | 12 bytes | -178000000 years | 178000000 years | 1 microsecond |
| date | dates only | 4 bytes | 4713 BC | 32767 AD | 1 day |
| time [ (p) ] [ without time zone ] | times of day only | 8 bytes | 00:00:00.00 | 23:59:59.99 | 1 microsecond |
| time [ (p) ] with time zone | times of day only | 12 bytes | 00:00:00.00+12 | 23:59:59.99-12 | 1 microsecond |
time, timestamp, et interval acceptent une valeur de précision p qui spécifie le nombre de chiffres dans le champ secondes. Par défaut, il n'y ap pas de frontière précise sur la précision. La limite effective de précision est déterminée par le nombre décimal de double précision utilisé pour stocker les valeurs (en secondes pour interval et en secondes depuis le 01-01-2000 pour timestamp). Le champ d'utilisation de p est de 0 à environ 6 pour timestamp, mais peut être plus pour interval. Le système acceptera une étendue de p de 0 à 13.
Les zones horaires, et les conventions de zones horaires, sont influencées par des décisions politiques, pas uniquement la géométrie terrestre. Les zones horaires dans la monde furent à peu près standardisées durant les années 1900, mais sont sujettes à des changements arbitraires. PostgreSQL utilise les fonctionnalités de votre système comme support des zones horaires, et ces sytèmes ne contiennent habituellement les informations que pour une période de temps allant de 1902 à 2038 (correspondant au système de gestion du temps des Unix). timestamp avec time zone et time avec time zone utiliseront les informations de zone horaire seulement dans cette échelle de temps et se réfèrent à la zone UTC/GMT.
Pour assurer la mise à jour des versions de PostgreSQL antérieures à la 7.0, les types datetime (équivalent à timestamp) et timespan (équivalent à interval) sont reconnus. Ces types sont maintenant restreints à une translation vers timestamp et interval, et leur support sera supprimé dans la prochaine version de PostgreSQL (nommée 7.3).
Les types abstime et reltime sont de précision plus faible et sont utilisés en interne. Nous vous déconseillons d'utiliser ces types dans de nouvelles applications et vous encourageons à faire les mises à jour. Certains ou tous ces types internes peuvent disparaître dans les prochaines versions.
Entrée Date/Time
L'entrée date et time est acceptée dans la plupart des formats, incluant ISO 8601, traditionnel SQL-compatible, PostgreSQL, et les autres. Pour certains formats, l'ordonnancement du mois et du jour dans l'entrée date peut être ambigu et il existe le support pour ordonner ces champs. La commande SET DateStyle TO 'US' ou SET DateStyle TO 'NonEuropean' spécifie la variante "le mois devant le jour", la commande SET DateStyle TO 'European' place la variante "le jour avant le mois". Le style ISO est utilisé par défaut mais peut être changé à la compilation ou au lancement.
PostgreSQL est plus flexible dans les date et time que le standard SQL. Voir the appendix called Support date/heure pour les règles exactes d'analyse des entrées date/time et pour la reconnaissance des champs texte incluant les mois, jours et semaines, ainsi que les zones horaires.
Souvenez vous que n'importe quelle entrée date ou time doit être insérée dans des apostrophes, comme les chaînes texte. Voir the section called Constantes d'autres types in the chapter called Syntaxe SQL pour plus d'information. SQL9x requiert la syntaxe suivante :
type [ (p) ] 'value' |
date
Les suivantes sont quelques entrées possibles pour le type date.
Table 11. Entrée date
| Exemple | Description |
|---|---|
| January 8, 1999 | Unambiguous |
| 1999-01-08 | ISO-8601 format, preferred |
| 1/8/1999 | U.S.; read as August 1 in European mode |
| 8/1/1999 | European; read as August 1 in U.S. mode |
| 1/18/1999 | U.S.; read as January 18 in any mode |
| 19990108 | ISO-8601 year, month, day |
| 990108 | ISO-8601 year, month, day |
| 1999.008 | Year and day of year |
| 99008 | Year and day of year |
| J2451187 | Julian day |
| January 8, 99 BC | Year 99 before the Common Era |
time [ ( p ) ] [ sans zone horaire ]
Pour SQL99, ce type peut être spécifié comme time ou comme time sans zone horaire. La précision optionnelle p pourrait être entre 0 et 13, et par défaut à la précision de l'entrée time littéral.
Les entrées time suivantes sont valides.
time [ ( precision ) ] avec zone horaire
Ce type est défini par SQL92, mais la définition montre des propriétés d'une utilité contestable. Dans la plupart des cas, une combinaison de date, time, timestamp sans time zone et timestamp avec time zone procurera les fonctionnalités requises par les applications.
La précision optionnelle p se situera entre 0 et 13, et par défaut la précision sera l'entrée time littérale.
time avec time zone accepte toutes les entrées légales pour le type time, jointes avec une zone horaire correcte, comme suit :
Table 13. Time avec entrée time zone
| Exemple | Description |
|---|---|
| 04:05:06.789-8 | ISO 8601 |
| 04:05:06-08:00 | ISO 8601 |
| 04:05-08:00 | ISO 8601 |
| 040506-08 | ISO 8601 |
Voir la Table 14 in the section called timestamp [ (precision) ] avec time zone pour d'avantage d'exemples de zones horaires.
timestamp [ (precision) ] sans time zone
Les entrées valides pour timestamp [ (p) ] sans le type time zone consiste en une concaténation d'une date et d'un time, suivis d'un AD ou BC optionnels, suivis d'un time zone également optionnel. (Voir plus bas). Ainsi
1999-01-08 04:05:06 |
January 8 04:05:06 1999 PST |
La précision optionnelle p se situera entre 0 et 13, et par défaut à la précision de l'entrée littérale timestamp.
Pour timestamp sans time zone, chaque zone horaire explicite spécifiée dans l'entrée est englouti silencieusement. Ceci étant, la valeur résultante date/time est dérivée des champs date/time dans la valeur entrée, et n'est pas ajustée pour time zone.
timestamp [ (precision) ] avec time zone
L'entrée valide pour le type timestamp consiste en une concaténation de date et time suivis de AD ou BC optionnels, également suivis d'un time zone optionnel. (Voir plus bas). AInsi
1999-01-08 04:05:06 -8:00 |
January 8 04:05:06 1999 PST |
La précision optionnelle p se situera entre 0 et 13, et par défaut à la précision d'une entrée littérale timestamp.
interval [ ( precision ) ]
les valeurs interval peuvent être écrites avec la syntaxe suivante :
Quantity Unit [Quantity Unit...] [Direction] @ Quantity Unit [Quantity Unit...] [Direction] |
Les qunatités de days, hours, minutes, et seconds peuvent être spécifiées sans unités explicites. Par exemple, '1 12:59:10' est lu comme '1 jour 12 hours 59 min 10 sec'.
La précision optionnelle p dare entre 0 et 13, et par défaut à la précision de l'entrée littérale.
Valeurs spéciales
Les fonctions compatibles SQL suivantes peuvent être utilisées comme entrées date et time pour les types correspondants : CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP. Les deux derniers acceptent la spécification de précision en option.
PostgreSQL supporte aussi plusieurs constantes spéciales pour des raisons de commodité.
Table 15. Constantes spéciales Date/Time
| Constante | Description |
|---|---|
| epoch | 1970-01-01 00:00:00+00 (temps zero des systèmes Unix) |
| infinity | Plus tard que les autres time valides |
| -infinity | Plus tôt que les autres time valides |
| invalid | Entrée non valide |
| now | Time de transaction en cours |
| today | Aujourd'hui à minuit |
| tomorrow | Demain à minuit |
| yesterday | Hier à minuit |
| zulu, allballs, z | 00:00:00.00 GMT |
 | Dans PostgreSQL version 7.2, 'current' n'est plus supporté comme constante date/time. Antérieurement, 'current' était stocké comme valeur spéciale, et évalué en tant que 'now' seulement quand il était utilisé dans une expression de type conversion. |
Sorties Date/Time
Les formats de sortie peuvent être indiqués dans un des quatre styles ISO 8601, SQL (Ingres), traditionnel PostgreSQL, et German, en utilisant SET DateStyle. Par défaut c'est le format ISO qui est utilisé.
Table 16. Style de sortie Date/Time
| Spécification du style | Description | Exemple |
|---|---|---|
| 'ISO' | ISO-8601 standard | 1997-12-17 07:37:16-08 |
| 'SQL' | Traditional style | 12/17/1997 07:37:16.00 PST |
| 'PostgreSQL' | Original style | Wed Dec 17 07:37:16 1997 PST |
| 'German' | Regional style | 17.12.1997 07:37:16.00 PST |
La sortie des styles date et time est bien sûr seulement la partie date et time en fonction des exemples ci-dessus.
Le style SQL possède des variantes européennes et non-européennes (U.S), qui déterminent que le mois suit le jour ou vice et versa. (Voir aussi the section called Entrée Date/Time pour l'interprétation des valeurs d'entrée.
Table 17. Conventions ordre de la date
| Spécification du style | Description | Exemple |
|---|---|---|
| European | jour/mois/année | 17/12/1997 15:37:16.00 MET |
| US | mois/jour/année | 12/17/1997 07:37:16.00 PST |
la sortie ressemble au format d'entrée, sauf que les unités comme week ou century sont converties en années et jours. En mode ISO les sorties ressemblent à ça :
[ Quantity Units [ ... ] ] [ Days ] Hours:Minutes [ ago ] |
Il y a plusieurs moyens de modifier l'apparence des types date/time :
La variable d'environnementPGDATESTYLE utilisée directement par le serveur au lancement du postmaster.
La variable d'environnement PGDATESTYLE utilisée par le client libpq au démarrage d'une session.
La commande SQL SET DATESTYLE.
Zones horaires
PostgreSQL s'efforce d'être compatible avec les définitions du SQL92 dans cet usage particulier. Cependant, le standard SQL92 rajoute un ensemble de types et possibilités date et time. Deux problèmes manifestes sont :
Bien que le type date n'ait pas de zone horaire associée, le type time peut en avoir une. Les zones horaires dans le monde réel peuvent ne pas avoir de signification à moins d'être associées avec une date et un time, mais le décalage peut varier dans l'année avec les limites de changement de jour.
La zone horaire par défaut est spécifiée comme entier constant du GMT/UTC. Il n'est pas possible d'adapter les limites de jour en faisant des date/time arithmétiques à travers DST.
Nous recommandons d'utiliser les types date/time qui contiennent ensemble la date et l'heure quand vous vous servez des zones horaires. Nous ne recommendons pas l'utilisation du type SQL92 time with time zone (bien qu'il soit supporté par PostgreSQL pour des raisons de compatibilité avec les autres SGBDR). PostgreSQL admet votre zone horaire locale pour tout type contenant seulement la date et l'heure. De plus, le support de la zone horaire est dérivée des possibilités de votre système d'exploitation.
PostgreSQL se procure le support des zones horaires à partir du système d'exploitation sous-jacent pour les dates entre 1902 et 2038 (proche des limites des systèmes Unix). En dehors de celle échelle, toutes les dates sont supposées être spécifiées et utilisées en GMT/UTC.
Toutes les dates et heures sont stockées en interne en UTC, connu sous le nom de Greenwich Mean Time (GMT). Les heures sont converties en heures locales par le serveur avant d'être envoyées au client.
Il existe plusieurs moyens de modifier le comportement des zones horaires:
La variable d'environnement TZ est utilisée directement par le serveur au lancement du postmaster en zone horaire par défaut.
La variable d'environnement PGTZ, si elle est indiquée par le client, est utilisée par libpq qui envoit une commande SET TIME ZONE au serveur au moment de la connexion.
La commande SQL SET TIME ZONE indique la zone horaire pour la session.
Le SQL92 qualifie
où zone peut être spécifié comme zone horaire en texte (ex. 'PST') ou comme intervalle (ex. INTERVAL '-08:00').timestamp AT TIME ZONE 'zone'
| Si une zone horaire invalide est spécifiée, celle-ci passera en GMT (sur la plupart des systèmes). |
| Si l'option de lancement AUSTRALIAN_TIMEZONES est placée CST et EST se réfèreront aux zones horaires australiennes, pas aux américaines. |
Internes
PostgreSQL utilise les dates juliennes pour tous les calculs de date/time. Elles ont la propriété de calculer/prédire correctement toute date plus récente que 4713 avant JC à loin dans le futur, en utilisant l'hypothèse que la longueur de l'année est de 365.2425 jours.
Les cconventions de date avant le 19e siècle sont intéressantes à lire, mais ne représentent pas suffisamment de garanties dans le codage de date/time.