Documentation PostgreSQL 9.5.4 -

Partie VIII. Annexes

B. Support de date/heure

PostgreSQL™ utilise un analyseur heuristique interne pour le support des dates/heures saisies. Les dates et heures, saisies sous la forme de chaînes de caractères, sont découpées en champs distincts après détermination du type d'information contenue dans chaque champ. Chaque champ est interpreté ; une valeur peut lui être affectée, il peut être ignoré ou encore être rejeté. Le parseur contient des tables de recherche internes pour tous les champs textuels y compris les mois, les jours de la semaine et les fuseaux horaires.

Cette annexe décrit le contenu des tables de correspondance et les méthodes utilisées par le parseur pour décoder les dates et heures.

B.1. Interprétation des Date/Heure saisies

Les entrées de type date/heure sont toutes décodées en utilisant le processus suivant.

  1. Diviser la chaîne saisie en lexèmes et catégoriser les lexèmes en chaînes, heures, fuseaux horaires et nombres.

    1. Si le lexème numérique contient un double-point (:), c'est une chaîne de type heure. On inclut tous les chiffres et double-points qui suivent.

    2. Si le lexème numérique contient un tiret (-), une barre oblique (/) ou au moins deux points (.), c'est une chaîne de type date qui contient peut-être un mois sous forme textuelle. Si un lexème de date a déjà été reconnu, il est alors interprété comme un nom de fuseau horaire (par exemple America/New_York).

    3. Si le lexème n'est que numérique alors il s'agit soit d'un champ simple soit d'une date concaténée ISO 8601 (19990113 pour le 13 janvier 1999, par exemple) ou d'une heure concaténée ISO 8601 (141516 pour 14:15:16, par exemple).

    4. Si le lexème débute par le signe plus (+) ou le signe moins (-), alors il s'agit soit d'un fuseau horaire numérique, soit d'un champ spécial.

  2. Si le lexème est une chaîne texte, le comparer avec les différentes chaînes possibles :

    1. Faire une recherche binaire dans la table pour vérifier si le lexème est une abréviation de fuseau horaire.

    2. S'il n'est pas trouvé, une recherche binaire est effectuée dans la table pour vérifier si le lexème est une chaîne spéciale (today, par exemple), un jour (Thursday, par exemple), un mois (January, par exemple), ou du bruit (at, on, par exemple).

    3. Si le lexème n'est toujours pas trouvé, une erreur est levée.

  3. Lorsque le lexème est un nombre ou un champ de nombre :

    1. S'il y a huit ou six chiffres, et qu'aucun autre champ date n'a été lu, alors il est interprété comme une « date concaténée » (19990118 ou 990118, par exemple). L'interprétation est AAAAMMJJ ou AAMMJJ.

    2. Si le lexème est composé de trois chiffres et qu'une année est déjà lue, alors il est interprété comme un jour de l'année.

    3. Si quatre ou six chiffres et une année sont déjà lus, alors il est interprété comme une heure (HHMM ou HHMMSS).

    4. Si le lexème est composé de trois chiffres ou plus et qu'aucun champ date n'a été trouvé, il est interprété comme une année (cela impose l'ordre aa-mm-jj des champs dates restants).

    5. Dans tous les autres cas, le champ date est supposé suivre l'ordre imposé par le paramêtre datestyle : mm-jj-aa, jj-mm-aa, ou aa-mm-jj. Si un champ jour ou mois est en dehors des limites, une erreur est levée.

  4. Si BC est indiqué, le signe de l'année est inversé et un est ajouté pour le stockage interne. (Il n'y a pas d'année zéro dans le calendrier Grégorien, alors numériquement 1 BC devient l'année zéro.)

  5. Si BC n'est pas indiqué et que le champ année est composé de deux chiffres, alors l'année est ajustée à quatre chiffres. Si le champ vaut moins que 70, alors on ajoute 2000, sinon 1900.

    [Astuce]

    Astuce

    Les années du calendrier Grégorien AD 1-99 peuvent être saisie avec 4 chiffres, deux zéros en tête (0099 pour AD 99, par exemple).

PrécédentCodes d'erreurs de PostgreSQL Niveau supérieurSommaire Mots clés Date/HeureSuivant