9.8. Fonctions de formatage des types de données

FM supprime les zéros de début et les espaces de fin qui, autrement, sont ajoutés pour fixer la taille du motif de sortie ; Dans PostgreSQL™, FM modifie seulement la prochaine spécification alors qu'avec Oracle, FM affecte toutes les spécifications suivantes et des modificateurs FM répétés bascule l'activation du mode de remplissage.

TM n'inclut pas les espaces de complétion en fin de chaîne ; to_timestamp et to_date ignore le modificateur TM.

to_timestamp et to_date ignorent les espaces multiples de la chaîne en entrée si l'option FX n'est pas utilisée. Par exemple, to_timestamp('2000    JUN', 'YYYY MON') fonctionne mais to_timestamp('2000    JUN', 'FXYYYY MON') renvoie une erreur car to_timestamp n'attend qu'une seule espace ; FX doit être indiqué comme premier élément du modèle.

to_timestamp et to_date existent pour gérer les formats en entrée qui ne peuvent pas être convertis par une conversion simple. Ces fonctions interprètent une entrée de façon libre, avec une vérification minimale des erreurs. Bien qu'elle produit une sortie valide, cette conversion peut générer des résultats inattendus. Par exemple, les données en entrée de ces fonctions ne sont pas restreintes par les intervalles habituels, du coup to_date('20096040','YYYYMMDD') renvoie 2014-01-17 plutôt que de causer une erreur. Une conversion standard n'aura pas ce comportement.

il est possible d'insérer du texte ordinaire dans les modèles to_char. il est alors littéralement remis en sortie. Une sous-chaîne peut être placée entre guillemets doubles pour forcer son interprétation en tant que libellé même si elle contient des mots clés de motif. Par exemple, dans '"Hello Year "YYYY', les caractères YYYY sont remplacés par l'année mais l'Y isolé du mot Year ne l'est pas ; Dans to_date, to_number et to_timestamp, les chaînes entre guillemets doubles ignorent le nombre de caractères en entrée contenus dans la chaîne, par exemple "XX" ignorent les deux caractères en entrée.

pour afficher un guillemet double dans la sortie, il faut le faire précéder d'un antislash. '\"YYYY Month\"', par exemple.

Si la spécification du format de l'année est inférieure à quatre chiffres, par exemple YYY et que l'année fournie est inférieure à quatre chiffres, l'année sera ajustée à l'année la plus proche de l'année 2020. Par exemple, 95 devient 1995.

la conversion YYYY d'une chaîne en champ de type timestamp ou date comporte une restriction avec les années à plus de quatre chiffres. Il faut alors utiliser un modèle ou un caractère non-numérique après YYYY, sans quoi l'année est toujours interprétée sur quatre chiffres. Par exemple, pour l'année 20000 : to_date('200001131', 'YYYYMMDD') est interprété comme une année à quatre chiffres ; il faut alors utiliser un séparateur non décimal après l'année comme to_date('20000-1131', 'YYYY-MMDD') ou to_date('20000Nov31', 'YYYYMonDD') ;

dans les conversions de chaîne en timestamp ou date, le champ CC (siècle) est ignoré s'il y a un champ YYY, YYYY ou Y,YYY. Si CC est utilisé avec YY ou Y, alors l'année est calculée comme l'année dans le siècle spécifié. Si le siècle est précisé mais pas l'année, la première année du siècle est utilisée ;

Une date ISO (distincte de la date grégorienne) peut être passée à to_timestamp et to_date de deux façons :

Essayer de construire une date en utilisant un mélange de champs de semaine ISO 8601 et de date grégorienne n'a pas de sens et renverra du coup une erreur. Dans le contexte d'une année ISO, le concept d'un « mois » ou du « jour d'un mois » n'a pas de signification. Dans le contexte d'une année grégorienne, la semaine ISO n'a pas de signification.

Attention

Alors que to_date rejette un mélange de champs de dates grégoriennes et ISO, to_char ne le fait pas car une spécification de format de sortie telle que YYYY-MM-DD (IYYY-IDDD) peut être utile. Mais évitez d'écrire quelque chose comme IYYY-MM-DD ; cela pourrait donner des résultats surprenants vers le début d'année (voir Section 9.9.1, « EXTRACT, date_part » pour plus d'informations).

les valeurs en millisecondes (MS) et microsecondes (US) dans une conversion de chaîne en champ de type timestamp sont utilisées comme partie décimale des secondes. Par exemple, to_timestamp('12:3', 'SS:MS') n'est pas 3 millisecondes mais 300 car la conversion le compte comme 12 + 0,3 secondes. Cela signifie que pour le format SS:MS, les valeurs d'entrée 12:3, 12:30 et 12:300 indiquent le même nombre de millisecondes. Pour obtenir trois millisecondes, il faut écrire 12:003 que la conversion compte comme 12 + 0,003 = 12,003 secondes.

Exemple plus complexe : to_timestamp('15:12:02.020.001230', 'HH24:MI:SS.MS.US') représente 15 heures, 12 minutes et (2 secondes + 20 millisecondes + 1230 microsecondes =) 2,021230 secondes ;

la numérotation du jour de la semaine de to_char(..., 'ID') correspond à la fonction extract(isodow from ...) mais to_char(..., 'D') ne correspond pas à la numération des jours de extract(dow from ...).

to_char(interval) formate HH et HH12 comme indiqué dans une horloge sur 12 heures, c'est-à-dire que l'heure 0 et l'heure 36 sont affichées 12, alors que HH24 affiche la valeur heure complète, qui peut même dépasser 23 pour les

un signe formaté à l'aide de SG, PL ou MI n'est pas ancré au nombre ; par exemple, to_char(-12, 'S9999') produit '  -12' mais to_char(-12, 'MI9999') produit '-  12'. L'implantation Oracle n'autorise pas l'utilisation de MI devant 9, mais requiert plutôt que 9 précède MI ;

9 est transformé en valeur avec le même nombre de chiffres qu'il y a de 9. Si un chiffre n'est pas disponible, il est remplacé par une espace ;

TH ne convertit pas les valeurs inférieures à zéro et ne convertit pas les nombres fractionnels ;

PL, SG et TH sont des extensions PostgreSQL™ ;

V avec to_char multiplie effectivement les valeurs en entrée par 10^n, où n est le nombre de chiffres qui suit V. V avec to_number divise de la même façon. to_char et to_number ne supportent pas l'utilisation de V combiné avec un point décimal (donc 99.9V99 n'est pas autorisé).

EEEE (notation scientifique) ne peut pas être utilisé en combinaison avec un des autres motifs de formatage ou avec un autre modificateur, en dehors des motifs chiffre et de point décimal, et doit être placé à la fin de la chaîne de format (par exemple, 9.99EEEE est valide).