FM supprime les zéros en début et les blancs à la fin qui pourraient avoir été ajoutés pour s'assurer d'une taille fix de la sortie. Dans PostgreSQL, FM modifie seulement la spécification suivante alors que dans Oracle, FM affecte toutes les spécifications suivantes, et des modificateurs FM répétés vont basculer l'activation et la désactivation du mode de remplissage.

TM supprime les espaces en fin de chaîne que FM soit spécifié ou non.

to_timestamp et to_date ignorent la casse des lettres en entrée ; donc par exemple MON, Mon, et mon acceptent toutes les mêmes chaînes. Lors de l'utilisation du modificateur TM, le changement de casse se fait suivant les règles de la collation pour les données en entrée de la fonction (voir Section 24.2).

to_timestamp et to_date ignorent les nombreux espaces blancs au début de la chaîne en entrée et autour des valeurs de date et d'heure sauf si l'option FX est utilisée. Par exemple, to_timestamp(' 2000    JUN', 'YYYY MON') et to_timestamp('2000 - JUN', 'YYYY-MON') fonctionnent, mais to_timestamp('2000    JUN', 'FXYYYY MON') renvoie une erreur parce que to_timestamp s'attend seulement à un seul espace. FX doit être spécifié comme premier élément dans le modèle.

Un séparateur (un espace ou un caractère qui n'est ni une lettre ni un chiffre) dans la chaîne modèle de to_timestamp et to_date correspond à tout séparateur dans la chaîne en entrée ou est ignoré, sauf si l'option FX est utilisée. Par exemple, to_timestamp('2000JUN', 'YYYY///MON') et to_timestamp('2000/JUN', 'YYYY MON') fonctionnent mais to_timestamp('2000//JUN', 'YYYY/MON') renvoie une erreur parce que le nombre de séparateurs dans la chaîne en entrée dépasse le nombre de séparateurs dans le modèle.

Si FX est indiqué, un séparateur dans la chaîne modèle correspond exactement à un caractère dans la chaîne en entrée. Mais notez que le caractère de la chaîne en entrée n'a pas besoin d'être identique au séparateur de la chaîne modèle. Par exemple, to_timestamp('2000/JUN', 'FXYYYY MON') fonctionne mais to_timestamp('2000/JUN', 'FXYYYY  MON') renvoie une erreur parce que le deuxième espace dans la chaîne modèle consomme la lettre J de la chaîne en entrée.

Un motif de modèle TZH peut correspondre à un nombre signé. Sans l'option FX, les signes moins pourraient être ambigus, et pourraient être interprétés comme un séparateur. Cette ambiguité est résolue ainsi ; si le nombre de séparateurs avant TZH dans la chaîne modèle est inférieur au nombre de séparateur avant le signe moins dans la chaîne en entrée, le signe moins est interprété comme faisant partie de TZH. Sinon le signe moins est considéré être un séparateur entre les valeurs. Par exemple, to_timestamp('2000 -10', 'YYYY TZH') fait correspondre -10 à TZH, mais to_timestamp('2000 -10', 'YYYY  TZH') fait correspondre 10 à TZH.

Un texte ordinaire est autorisé dans les modèles to_char et sera affiché littéralement. Vous pouvez placer une sous-chaîne entre des guillemets doubles pour forcer son interprétation comme un texte littéral, même s'il contient des motifs de modèle. Par exemple, dans '"Hello Year "YYYY', le texte YYYY sera remplacé par l'année, mais le simple Y dans Year ne le sera pas. Dans to_date, to_number et to_timestamp, le texte littéral et les chaînes entre guillemets doubles finissent en ignorant le nombre de caractères contenus dans la chaîne ; par exemple, "XX" ignore les deux caractères en entrée (qu'ils soient ou non XX).

Si vous voulez avoir un guillemet double dans la sortie, vous devez la précéder avec un antislash, par exemple '\"YYYY Month\"'. En dehors de cela, les antislashs ne sont pas particulièrement spéciaux en dehors des chaînes entre guillemets doubles. À l'intérieur d'une chaîne entre guillemets doubles, un antislash peut faire que le prochain caractère soit considéré littéralement, quel qu'il soit (mais ceci n'a pas d'effet spécial sauf si le caractère suivant est un guillemet double ou un autre antislash).

Dans to_timestamp et to_date, si la spécification du format de l'année fait moins de quatre chiffres, donc YYY, et que l'année indiquée fait moins de quatre chiffres, l'année sera ajustée au plus proche de l'année 2020, donc 95 devient 1995.

Dans to_timestamp et to_date, les années négatives sont traitées comme signifiant avant Jésus Christ. Si vous écrivez à la fois une année négative et un champ BC explicite, vous obtenez après Jésus Christ de nouveau. Une entrée année zéro est traitée comme l'année 1 après Jésus Christ.

Dans to_timestamp et to_date, la conversion YYYY a une restriction lors du traitement d'années avec plus de 4 chiffres. Vous devez utiliser certains caractères qui ne sont pas des chiffres ou un modèle après YYYY, sinon l'année est toujours interprétée avec 4 chiffres. Par exemple (avec l'année 20000) : to_date('200001130', 'YYYYMMDD') sera interprété comme une année sur 4 chiffres ; à la placez, utilisez un séparateur qui n'est pas un chiffre après l'année, comme par exemple to_date('20000-1130', 'YYYY-MMDD') ou to_date('20000Nov30', 'YYYYMonDD').

Dans to_timestamp et to_date, le champ CC (siècle) est accepté mais ignoré s'il existe un champ YYY, YYYY ou Y,YYY. Si CC est utilisé avec YY ou Y, alors le résultat est calculé comme l'année dans le siècle spécifié. Si le siècle est spécifié, mais pas l'année, la première année du siècle est présumée.

Dans to_timestamp et to_date, les noms ou numéros des jours de la semaine (DAY, D, et les champs relatifs) sont acceptés mais ignorés pour calculer le résultat. Ceci est vrai aussi pour le champ Q.

Dans to_timestamp et to_date, une date d'après la numérotation ISO 8601 (dans le sens distinct d'une date grégorienne) peut être indiqué de deux façons :

Tenter de saisir une date en utilisant un mix de champs ISO 8601 et de champs grégoriens n'a pas de sens, et résultera en une erreur. Dans le contexte année-numéro de semaine sous l'ISO 8601, 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.

Dans to_timestamp, les champs milliseconde (MS) et microseconde (US) sont utilisés comme les chiffres secondes après le point décimal. Par exemple, to_timestamp('12.3', 'SS.MS') ne vaut pas 3 millisecondes, mais 300 parce que la conversion la traite comme 12 + 0,3 secondes. Donc, pour le format SS.MS, les valeurs en entrée 12.3, 12.30 et 12.300 spécifient le même nombre de millisecondes. Pour obtenir trois millisecondes, il faut écrire 12.003, que la conversion traite comme 12 + 0,003 = 12,003 secondes.

Voici un exemple plus complexe : to_timestamp('15:12:02.020.001230', 'HH24:MI:SS.MS.US') est 15 heures, 12 minutes, et 2 secondes + 20 millisecondes + 1230 microsecondes = 2,021230 secondes.

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

to_char(interval) formate HH et HH12 comme indiqué sur une horloge 12-heures, par exemple; l'heure zéro et l'heure 36 s'affichent toutes les deux comme 12, alors que HH24 affiche la valeur complète de l'heure qui peut dépasser 23 dans une valeur de type interval.

0 spécifie une position de chiffre qui sera toujours affiché, même s'il contient un zéro en début ou en fin. 9 spécifie aussi une position de chiffre mais, s'il s'agit un zéro en début, alors il sera remplacé par un espace, alors que s'il s'agit d'un zéro en fin et que le mode de remplissage est activé, alors il sera supprimé. (Pour to_number(), ces deux modèles sont équivalents.)

si le format fournit moins de chiffres décimaux que le nombre en cours de formatage, to_char() arrondira le nombre du nombre indiqué de chiffres décimaux.

Les caractères de modèle S, L, D et G représentent le signe, le symbôle de monnaie, le point décimal et le séparateur de milliers définis par la locale actuelle (voir lc_monetary et lc_numeric). Le point et la virgule représentent ces caractères avec la signification du point décimal et du séparateur de milliers, quelque soit la locale.

Si aucune provision explicite n'est faite pour un signe dans le motif de to_char(), une colonne sera réservée pour le signe, et il sera ancré au chiffre (il apparaîtra à gauche). Si S apparaît juste à gauche de 9, il sera quand même ancré au nombre.

Un signe formaté utilisant SG, PL ou MI n'est pas ancré au nombre ; par exemple, to_char(-12, 'MI9999') produit '-  12' mais to_char(-12, 'S9999') produit '  -12'. (L'implémentation Oracle ne permet pas l'utilisation de MI avant 9, mais nécessite plutôt que 9 précède MI.)

TH ne convertit pas les valeurs inférieures à zéro et ne convertit pas les nombres fractionnés.

PL, SG et TH sont des extensions de PostgreSQL.

Dans to_number, si des motifs de modèle non-données tels que L ou TH sont utilisés, le nombre correspondant de caractères en entrée est ignoré qu'ils correspondent ou non au motif du modèle, sauf si ce sont des caractères de données (c'est-à-dire chiffres, signe, point décimal ou virgule). Par exemple, TH ignorerait les deux caractères qui ne sont pas des données.

V avec to_char multiplie les valeurs en entrée par 10^n, où n est le nombre de chiffres suivant V. V avec to_number divise d'une façon similaire. to_char et to_number ne supportent pas l'utilisation de V en combinaison avec un point décimal (de ce fait, 99.9V99 n'est pas autorisé).

EEEE (notation scientifique) ne peut pas être utilisé en combinaison avec tout autre motif de formatage ou modificateur autre que les motifs de chiffres et de point décimal, et doit être à la fin de la chaîne de format (autrement dit, 9.99EEEE est un motif valide).