8.5. Types date/heure
PostgreSQL™ supporte
l'ensemble des types date et heure du SQL. Ces types sont présentés dans le Tableau 8.9,
« Types date et heure ». Les opérations disponibles sur
ces types de données sont décrites dans la Section 9.9,
« Fonctions et opérateurs sur date/heure ».
Tableau 8.9. Types date et heure
|
Nom
|
Taille de stockage
|
Description
|
Valeur minimale
|
Valeur maximale
|
Résolution
|
|
timestamp [ (
p
) ] [ without time zone
]
|
8 octets
|
date et heure
|
4713 avant JC
|
5874897 après JC
|
1 microseconde / 14 chiffres
|
|
timestamp [ (
p
) ] with time zone
|
8 octets
|
date et heure, avec fuseau horaire
|
4713 avant JC
|
5874897 après JC
|
1 microseconde / 14 chiffres
|
|
interval [ (
p
) ]
|
12 octets
|
intervalle de temps
|
-178000000 années
|
178000000 années
|
1 microseconde / 14 chiffres
|
|
date
|
4 octets
|
date seule
|
4713 avant JC
|
5874897 après JC
|
1 jour
|
|
time [ (
p
) ] [ without time zone
]
|
8 octets
|
heure seule
|
00:00:00.00
|
24:00:00
|
1 microseconde / 14 chiffres
|
|
time [ (
p
) ] with time zone
|
12 octets
|
heure seule, avec fuseau horaire
|
00:00:00+1459
|
24:00:00-1459
|
1 microseconde / 14 chiffres
|
![[Note]](images/note.png)
Note
Précédemment à PostgreSQL™
7.3, n'écrire que timestamp équivalait
à timestamp with time zone. Cela a été
modifié pour des raisons de compatibilité avec le standard SQL.
time, timestamp,
et interval acceptent une précision
optionnelle
p
, qui indique le
nombre de décimales pour les secondes. Il n'y a pas, par défaut, de
limite explicite à cette précision. Les valeurs acceptées pour
p
s'étendent de 0 à 6 pour les
types timestamp et interval.
Note
Quand les valeurs timestamp sont
stockées en tant que nombre à virgule flottante de précision
double (par défaut à l'heure actuelle), la limite réelle de la
précision peut être inférieure à 6. Les valeurs timestamp sont stockées comme un nombre de secondes
avant ou après le 1er janvier 2000 à minuit. La précision à la
microseconde est obtenue pour les dates proches du 1er janvier
2000, mais elle se dégrade pour les dates plus éloignées. Quand
les valeurs timestamp sont stockées sur
des entiers de huit octets (une option de compilation), la
précision en microseconde est disponible sur toute l'étendue de
valeurs. Néanmoins, les valeurs de type timestamp codées sur des
entiers de huit octets ont une échelle de date plus restreinte
que celle indiquée ci-dessus : de 4713 avant Jésus-Christ à
294276 après Jésus-Christ. La même option de compilation
détermine si les valeurs time et
interval sont stockées comme nombres à
virgule flottante ou comme entiers sur huit octets. Dans le cas
de la virgule flottante, la précision des grandes valeurs
interval se dégradent à mesure que
l'intervalle croît.
Pour les types time, l'intervalle accepté
pour
p
s'étend de 0 à 6 pour
les entiers sur 8 octets et de 0 à 10 pour les nombres à virgule
flottante.
Le type time with time zone est défini dans
le standard SQL mais sa définition lui prête des propriétés qui font
douter de son utilité. Dans la plupart des cas, une combinaison de
date, time,
timestamp without time zone et timestamp with time zone devrait permettre de résoudre
toutes les fonctionnalités de date et heure nécessaires à une
application.
Les types abstime et reltime sont des types de précision moindre, utilisés
en interne. Il n'est pas recommandé de les utiliser dans de nouvelles
applications. Au contraire, il est souhaitable de migrer l'existant
vers un autre type approprié. Il est probable que l'un ou l'autre
(voire tous) de ces types internes disparaisse(nt) dans une future
version.
8.5.1. Saisie des dates et heures
La saisie de dates et heures peut se faire dans la plupart des
formats raisonnables, dont ISO8601, tout format compatible avec
SQL, le format POSTGRES™ traditionnel ou autres. Pour
certains formats, l'ordre des jours, mois et années en entrée est
ambigu. Il est alors possible de préciser l'ordre attendu pour ces
champs. Le paramètre datestyle peut être
positionné à MDY pour choisir une
interprétation mois-jour-année, à DMY pour
jour-mois-année ou à YMD pour
année-mois-jour.
PostgreSQL™ est plus
flexible que la norme SQL ne
l'exige pour la manipulation des dates et des heures. Voir
l'Annexe B, Support
de date/heure pour connaître les règles exactes de
reconnaissance des dates et heures et les formats reconnus pour les
champs texte comme les mois, les jours de la semaine et les fuseaux
horaires.
Tout libellé de date ou heure saisi doit être placé entre
apostrophes, comme les chaînes de caractères. La Section 4.1.2.5,
« Constantes d'autres types » peut être consultée
pour plus d'information. SQL
requiert la syntaxe suivante :
type [ (p) ] 'valeur'
où
p
, précision optionnelle,
est un entier correspondant au nombre de décimales du champ
secondes. La précision peut être précisée pour les types
time, timestamp, et interval. Les
valeurs admissibles sont mentionnées plus haut. Si aucune précision
n'est indiquée dans une déclaration de constante, celle de la
valeur littérale est utilisée.
Le Tableau 8.10,
« Saisie de date » regroupe les formats de date
possibles pour la saisie de valeurs de type date.
Tableau 8.10. Saisie de date
|
Exemple
|
Description
|
|
January 8, 1999
|
sans ambiguïté quel que soit le style de date
(datestyle)
|
|
1999-01-08
|
ISO-8601 ; 8 janvier, quel que soit le mode (format
recommandé)
|
|
1/8/1999
|
8 janvier en mode MDY ; 1er
août en mode DMY
|
|
1/18/1999
|
18 janvier en mode MDY ;
rejeté dans les autres modes
|
|
01/02/03
|
2 janvier 2003 en mode MDY ;
1er février 2003 en mode DMY ;
3 février 2001 en mode YMD
|
|
1999-Jan-08
|
8 janvier dans tous les modes
|
|
Jan-08-1999
|
8 janvier dans tous les modes
|
|
08-Jan-1999
|
8 janvier dans tous les modes
|
|
99-Jan-08
|
8 janvier en mode YMD, erreur
sinon
|
|
08-Jan-99
|
8 janvier, sauf en mode YMD :
erreur
|
|
Jan-08-99
|
8 janvier, sauf en mode YMD :
erreur
|
|
19990108
|
ISO-8601 ; 8 janvier 1999 dans tous les modes
|
|
990108
|
ISO-8601 ; 8 janvier 1999 dans tous les modes
|
|
1999.008
|
Année et jour de l'année
|
|
J2451187
|
Jour du calendrier Julien
|
|
January 8, 99 BC
|
année 99 avant Jésus Christ
|
Les types heure-du-jour sont time [
(
p
) ] without time
zone et time [ (
p
) ] with time zone.
time est équivalent à time without time zone.
Les saisies valides pour ces types sont constituées d'une heure
suivie éventuellement d'un fuseau horaire (voir le Tableau 8.11,
« Saisie d'heure » et le Tableau 8.12,
« Saisie des fuseaux horaires »). Si un fuseau est
précisé pour le type time without time
zone, il est ignoré sans message d'erreur. Si une date est
indiquée, elle est ignorée sauf si un fuseau horaire impliquant
une règle de changement d'heure (heure d'été/heure d'hiver) est
précisé, America/New_York par exemple.
Dans ce cas, la date est nécessaire pour pouvoir déterminer la
règle de calcul de l'heure qui s'applique. Le décalage approprié
du fuseau horaire est enregistré dans la valeur de time with time zone.
Tableau 8.11. Saisie d'heure
|
Exemple
|
Description
|
|
04:05:06.789
|
ISO 8601
|
|
04:05:06
|
ISO 8601
|
|
04:05
|
ISO 8601
|
|
040506
|
ISO 8601
|
|
04:05 AM
|
Identique à 04:05 ; AM n'affecte pas la valeur
|
|
04:05 PM
|
Identique à 16:05 ; l'heure doit être <= 12
|
|
04:05:06.789-8
|
ISO 8601
|
|
04:05:06-08:00
|
ISO 8601
|
|
04:05-08:00
|
ISO 8601
|
|
040506-08
|
ISO 8601
|
|
04:05:06 PST
|
fuseau horaire abrégé
|
|
2003-04-12 04:05:06
America/New_York
|
fuseau horaire en nom complet
|
Tableau 8.12. Saisie des fuseaux horaires
|
Exemple
|
Description
|
|
PST
|
Abréviation pour l'heure standard du Pacifique (Pacific
Standard Time)
|
|
America/New_York
|
Nom complet du fuseau horaire
|
|
PST8PDT
|
Nommage POSIX du fuseau horaire
|
|
-8:00
|
Décalage ISO-8601 pour la zone PST
|
|
-800
|
Décalage ISO-8601 pour la zone PST
|
|
-8
|
Décalage ISO-8601 pour la zone PST
|
|
zulu
|
Abréviation militaire de GMT
|
|
z
|
Version courte de zulu
|
L'Section 8.5.3, « Fuseaux
horaires » apporte des précisions quant à la façon
d'indiquer les fuseaux horaires.
Les saisies valides sont constituées de la concaténation d'une
date et d'une heure, éventuellement suivie d'un fuseau horaire et
d'un qualificatif AD (après Jésus
Christ) ou BC (avant Jésus Christ).
(AD/BC peut
aussi apparaître avant le fuseau horaire mais ce n'est pas
l'ordre préféré.) Ainsi :
1999-01-08 04:05:06
et
1999-01-08 04:05:06 -8:00
sont des valeurs valides, qui suivent le standard ISO 8601. Le format très courant
January 8 04:05:06 1999 PST
est également supporté.
Le standard SQL différencie
les libéllés timestamp without time
zone et timestamp with time zone
par la présence d'un « + »
ou d'un « - ». De ce fait,
d'après le standard,
TIMESTAMP '2004-10-19 10:23:54'
est du type timestamp without time zone
alors que
TIMESTAMP '2004-10-19 10:23:54+02'
est du type timestamp with time zone.
PostgreSQL™ n'examine
jamais le contenu d'un libellé avant de déterminer son type. Du
coup, il traite les deux ci-dessus comme des valeurs de type
timestamp without time zone. Pour
s'assurer qu'un littéral est traité comme une valeur de type
timestamp with time zone, il faut
préciser explicitement le bon type :
TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
Dans un libellé de type timestamp without time
zone, PostgreSQL™
ignore silencieusement toute indication de fuseau horaire.
C'est-à-dire que la valeur résultante est dérivée des champs
date/heure de la valeur saisie et n'est pas corrigée par le
fuseau horaire.
Pour timestamp with time zone, la
valeur stockée en interne est toujours en UTC (
Universal Coordinated
Time
ou Temps Universel Coordonné), aussi connu sous
le nom de GMT (
Greenwich Mean
Time
). Les valeurs saisies avec un fuseau horaire
explicite sont converties en UTC à l'aide du décalage approprié.
Si aucun fuseau horaire n'est précisé, alors le système considère
que la date est dans le fuseau horaire indiqué par le paramètre
système timezone, et la
convertit en UTC en utilisant le décalage de la zone timezone.
Quand une valeur timestamp with time
zone est affichée, elle est toujours convertie de l'UTC
vers le fuseau horaire courant (variable timezone), et affichée comme une heure locale.
Pour voir l'heure dans un autre fuseau horaire, il faut, soit
changer la valeur de timezone, soit
utiliser la construction AT TIME ZONE
(voir la Section 9.9.3, « AT TIME ZONE »).
Les conversions entre timestamp without time
zone et timestamp with time zone
considèrent normalement que la valeur timestamp without time zone utilise le fuseau
horaire timezone. Un fuseau différent
peut être choisi en utilisant AT TIME
ZONE.
Les valeurs de type interval utilisent
la syntaxe suivante :
[@] quantité unité [quantité unité...] [direction]
où :
quantité
est un nombre
(éventuellement signé) ;
unité
est microsecond, millisecond,
second, minute,
hour, day,
week, month,
year, decade,
century, millennium, une abbréviation ou un pluriel de ces
unités ;
direction
peut
être ago ou vide. L'arobase (@) est optionnel. Les valeurs des différentes
unités sont implicitement ajoutées en utilisant le signe
approprié.
Les nombres de jours, heures, minutes et secondes peuvent être
précisées sans unité explicite. Par exemple '1 12:59:10' est compris de la même façon que
'1 day 12 hours 59 min 10 sec' (1 jour,
12 heures, 59 minutes, 10 secondes).
La précision optionnelle, en dessous de la seconde, doit être
comprise entre 0 et 6, et prend la précision du libellé saisi
comme valeur par défaut.
En interne, les valeurs interval sont
enregistrées comme des mois, jours et secondes. Ceci parce que le
nombre de jours d'un mois varie et qu'un jour peut avoir 23 ou 25
heures si un changement d'heure s'applique. Comme les intervalles
sont habituellement créés à partir de chaînes de caractères
constantes ou de soustraction de timestamp, cette méthode de stockage fonctionne
bien dans la majorité des cas. Les fonctions justify_days et justify_hours sont disponibles pour ajuster les
jours et les heures qui dépassent leurs périodes habituelles.
8.5.1.5. Valeurs spéciales
PostgreSQL™ supporte
plusieurs valeurs de dates spéciales, dans un souci de
simplification. Ces valeurs sont présentées dans le Tableau 8.13,
« Saisie de dates/heures spéciales ». Les valeurs
infinity et -infinity ont une représentation spéciale dans le
système et sont affichées ainsi ; les autres ne sont que des
raccourcies de notation convertis en dates/heures ordinaires
lorsqu'ils sont lus. (En particulier, now et les chaînes relatives sont converties en
une valeur de temps spécifique à leur lecture). Toutes ces
valeurs doivent être écrites entre simples quotes lorsqu'elles
sont utilisées comme des constantes dans les commandes SQL.
Tableau 8.13. Saisie de dates/heures spéciales
|
Saisie
|
Types valides
|
Description
|
|
epoch
|
date, timestamp
|
1970-01-01 00:00:00+00 (date système zéro d'Unix)
|
|
infinity
|
timestamp
|
plus tard que toutes les autres dates
|
|
-infinity
|
timestamp
|
plus tôt que toutes les autres dates
|
|
now
|
date, time, timestamp
|
heure de démarrage de la transaction courante
|
|
today
|
date, timestamp
|
aujourd'hui minuit
|
|
tomorrow
|
date, timestamp
|
demain minuit
|
|
yesterday
|
date, timestamp
|
hier minuit
|
|
allballs
|
time
|
00:00:00.00 UTC
|
Les fonctions suivantes, compatibles avec le standard
SQL, peuvent aussi être
utilisées pour obtenir l'heure courante pour le type de données
correspondant : CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. Les quatre derniers acceptent une
indication optionnelle de précision en dessous de la seconde
(voir la Section 9.9.4,
« Date/Heure courante »). Ce sont là des fonctions
SQL qui ne sont
pas
reconnues comme chaînes de saisie de données.
8.5.2. Affichage des dates et heures
Le format de sortie des types date/heure peut être positionné à
l'un des quatre formats de date suivants : ISO 8601,
SQL (Ingres), traditionnel
POSTGRES et German (germanique). Cela se fait à l'aide de la
commande SET datestyle. Le format par
défaut est le format ISO. (Le
standard SQL impose
l'utilisation du format ISO 8601. Le nom du format d'affichage
« SQL » est un accident
historique.) Le Tableau 8.14,
« Styles d'affichage de date/heure » présente des
exemples de chaque format d'affichage. La sortie d'un type
date ou time
n'est évidemment composée que de la partie date ou heure, comme
montré dans les exemples.
Tableau 8.14. Styles d'affichage de date/heure
|
Spécification de style
|
Description
|
Exemple
|
|
ISO
|
standard ISO 8601/SQL
|
1997-12-17 07:37:16-08
|
|
SQL
|
style traditionnel
|
12/17/1997 07:37:16.00 PST
|
|
POSTGRES
|
style original
|
Wed Dec 17 07:37:16 1997 PST
|
|
German
|
style régional
|
17.12.1997 07:37:16.00 PST
|
Dans les styles SQL et POSTGRES,
les jours apparaissent avant le mois si l'ordre des champs DMY a
été précisé, sinon les mois apparaissent avant les jours (voir la
Section 8.5.1,
« Saisie des dates et heures » pour savoir comment ce
paramètre affecte l'interprétation des valeurs en entrée). Le
Tableau 8.15,
« Convention de présentation des dates » présente un
exemple.
Tableau 8.15. Convention de présentation des
dates
|
Valeur de datestyle (style de
date)
|
Ordre de saisie
|
Exemple d'affichage
|
|
SQL, DMY
|
jour
/
mois
/
année
|
17/12/1997 15:37:16.00 CET
|
|
SQL, MDY
|
mois
/
jour
/
année
|
12/17/1997 07:37:16.00 PST
|
|
Postgres, DMY
|
jour
/
mois
/
année
|
Wed 17 Dec 07:37:16 1997 PST
|
L'affichage du type interval ressemble au
format de saisie, à ceci près que les unités comme century ou week sont
converties en années et jours, et que ago
est converti en un signe approprié. En mode ISO, l'affichage
ressemble à :
[ quantité unité [ ... ] ] [ jours ] [ heures:minutes:secondes ]
Les styles de date/heure peuvent être sélectionnés à l'aide de la
commande
SET
datestyle
, du paramètre datestyle du fichier
de configuration postgresql.conf ou par
la variable d'environnement PGDATESTYLE sur
le serveur ou le client. La fonction de formatage to_char (voir Section 9.8,
« Fonctions de formatage des types de données »)
permet de formater les affichages de date/heure de manière plus
flexible.
Les fuseaux horaires et les conventions liées sont influencées par
des décisions politiques, pas uniquement par la géométrie de la
terre. Les fuseaux horaires se sont quelque peu standardisés au
cours du vingtième siècle mais continuent à être soumis à des
changements arbitraires, particulièrement en respect des règles de
changement d'heure (heure d'été/heure d'hiver). PostgreSQL™ gère actuellement les règles
de changement d'heure pour la période de 1902 à 2038 (qui
correspond à l'intégralité de l'échelle du temps système Unix). Les
heures en dehors de cette échelle sont prises dans le
« temps standard » du fuseau
horaire sélectionné, quelque soit la partie de l'année où elles
tombent.
PostgreSQL™ se veut
compatible avec les définitions standard SQL pour un usage typique. Néanmoins, le
standard SQL possède un mélange
étrange de types de date/heure et de possibilités. Deux problèmes
évidents sont :
-
bien que le type date n'ait pas de
fuseau horaire associé, le type heure peut en avoir un. Les fuseaux horaires,
dans le monde réel, ne peuvent avoir de sens qu'associés à
une date et à une heure, vu que l'écart peut varier avec
l'heure d'été ;
-
le fuseau horaire par défaut est précisé comme un écart
numérique constant avec l'UTC. Il n'est, de ce fait, pas possible
de s'adapter à l'heure d'été ou d'hiver lorsque l'on fait des
calculs arithmétiques qui passent les limites de l'heure
d'été et de l'heure d'hiver.
Pour éviter ces difficultés, il est recommandé d'utiliser des types
date/heure qui contiennent à la fois une date et une heure lorsque
les fuseaux horaires sont utilisés. Il est également préférable de
ne pas
utiliser le type
time with time zone. (Ce type est
néanmoins proposé par PostgreSQL™ pour les applications
existantes et pour assurer la compatibilité avec le standard
SQL.) PostgreSQL™ utilise le fuseau horaire
local pour tous les types qui ne contiennent qu'une date ou une
heure.
Toutes les dates et heures liées à un fuseau horaire sont stockées
en interne en UTC. Elles sont
converties en heure locale dans le fuseau indiqué par le paramètre
de configuration timezone avant d'être
affiché sur le client.
PostgreSQL™ permet
d'indiquer les fuseaux horaires de trois façons différentes :
-
un nom complet de fuseau horaire, par exemple America/New_York. Les noms reconnus de fuseau
horaire sont listés dans la vue pg_timezone_names (voir Section 43.49,
« pg_timezone_names »).
PostgreSQL™ utilise
les données zic pour cela, les mêmes
noms sont donc reconnus par de nombreux autres logiciels ;
-
une abréviation de fuseau horaire, par exemple PST. Une telle indication ne définit qu'un
décalage particulier à partir d'UTC, en contraste avec les
noms complets de fuseau horaire qui peuvent aussi impliquer
un ensemble de dates pour le changement d'heure. Les
abréviations reconnues sont listées dans la vue pg_timezone_abbrevs (voir Section 43.48,
« pg_timezone_abbrevs »). Le
paramètre de configuration timezone ne
peut pas être configuré à l'aide d'une abréviation de fuseau
horaire, mais ces abréviations peuvent être utilisées dnas
les saisies de date/heure et avec l'opérateur AT TIME ZONE ;
-
une spécification POSIX de fuseau sous la forme
STD
décalage
ou
STD
décalage
DST
avec
STD
une abréviation de fuseau et
décalage
un décalage
numérique en nombre d'heures à l'ouest d'UTC et
DST
une abréviation optionnelle
de changement d'heure, à interpréter comme une heure avant le
décalage donné. Par exemple si EST5EDT n'est pas déjà reconnu comme fuseau
horaire, il est accepté et est fonctionnellement équivalent à
l'heure du fuseau de la côte est des USA. Si un nom de
changement d'heure est présent, il est interprété selon les
règles régissant les changements d'heure utilisées dans
l'entrée posixrules de la base de
données des fuseaux horaires, zic.
Dans une installation PostgreSQL™ standard, posixrules est identique à US/Eastern, pour que les spécifications POSIX
des fuseaux horaires correspondent aux règles de changements
d'heure aux États-Unis. Ce comportement peut, au besoin, être
ajusté en remplaçant le fichier posixrules.
Il y a une différence conceptuelle et pratique entre les
abréviations et les noms complets : les abréviations représentent
toujours un décalage fixe par rapport à UTC alors que la plupart
des noms complets impliquent une règle de changement d'heure et
donc deux décalages possibles.
La fonctionnalité des fuseaux horaires POSIX peut accepter
silencieusement des saisies erronées car il n'y a pas de
vérification des abréviations de fuseaux horaires. Par exemple,
SET TIMEZONE TO FOOBAR0 fonctionne mais
conduit le système à utiliser en réalité une abréviation très
particulière d'UTC.
Dans tous les cas, les noms des fuseaux horaires sont insensibles à
la casse. (C'est un changement par rapport aux versions de
PostgreSQL™ antérieures à la
8.2 qui étaient sensibles à la casse dans certains cas et pas dans
d'autres.)
Ni les noms complets ni les abréviations ne sont codés en dur dans
le serveur ; ils sont obtenus à partir des fichiers de
configuration stockés sous .../share/timezone/ et .../share/timezonesets/ du répertoire
d'installation (voir Section B.3,
« Fichiers de configuration date/heure »).
Le paramètre de configuration timezone peut être
fixé dans le fichier postgresql.conf ou
par tout autre moyen standard décrit dans le Chapitre 17,
Configuration du serveur. Il existe aussi quelques manières
spéciales de le configurer :
-
si timezone n'est précisé ni dans
postgresql.conf ni comme une option
en ligne de commande du serveur, le serveur tente d'utiliser
la valeur de la variable d'environnement TZ comme fuseau horaire par défaut. Si
TZ n'est pas définie ou ne fait pas
partie des noms de fuseau horaire connus par PostgreSQL™, le serveur tente de
déterminer le fuseau horaire par défaut du système
d'exploitation en vérifiant le comportement de la fonction
localtime() de la bibliothèque C. Le
fuseau horaire par défaut est sélectionné comme la
correspondance la plus proche parmi les fuseaux horaires
connus par PostgreSQL™
;
-
la commande SQL
SET TIME ZONE
configure le fuseau horaire pour une session. C'est une autre
façon d'indiquer
SET TIMEZONE
TO
avec une syntaxe plus compatible avec les
spécifications SQL ;
-
la variable d'environnement PGTZ, si
le client la positionne, est utilisée par les applications
fondées sur libpq pour
envoyer une commande
SET TIME
ZONE
au serveur lors de la connexion.
PostgreSQL™ utilise les
dates du calendrier Julien pour tous les calculs de date/heure.
Elles ont la propriété intéressante de permettre le calcul de toute
date depuis 4713 avant Jésus Christ jusque loin dans le futur, avec
pour seule hypothèse que l'année dure 365,2425 jours.
Les conventions pour les dates antérieures au 19ème siècle sont
d'une lecture intéressante mais ne sont pas assez cohérentes pour
être codées dans un gestionnaire de dates.
|
Types de données binaires
