Dopez vos traitements de dates avec les champs nuls

Le concept de dates nulles n’est pas vraiment nouveau. Depuis toujours, nous rencontrons
des dates qui n’ont pas encore servi ou qui ne serviront peut-être jamais. Ainsi,
le fichier du personnel contient des champs dates de début et de fin d’emploi,
mais il est très rare que nous connaissions cette dernière au moment où nous ajoutons
cette personne au fichier. De même, certains fichiers clients contiennent des
champs de date qui ne serviront peut-être jamais, comme « Limite de crédit dépassée »
et « Date de notification ». Et, dans un fichier produits, certains enregistrements
possèdent un champ « Date de péremption » dont d’autres sont dépourvus.

Jadis, les programmeurs traitaient parfois de tels champs en leur attribuant une
valeur fictive, comme 31/12/99 (même s’ils regrettent amèrement ce choix à  l’approche
du vrai 31/12/99 ! ! !). Ma stratégie préférée en matière de date nulle consistait
à  entrer des zéros partout pour un champ de date facultatif (si (IF) une date
était différente de zéro, alors (THEN) c’était forcément une date valide). Facile
à  coder, simple à  comprendre, une date à  zéro n’était rien d’autre qu’une date
nulle. De plus, il était facile d’imprimer des dates à  zéro en RPG. Un code édition
Y produisait 0/00/00 pour de telles dates, et un mot d’édition  » / /  » produisait
une zone vierge, sans les barres obliques.

Mais, me direz-vous, si les dates à  zéro fonctionnent et existent depuis des années,
à  quoi sert cette nouvelle « date nulle » ? Et bien, c’est que nos anciens champs
« date » n’étaient pas vraiment des champs date, mais plutôt de simples champs zonés
ou packés dont nous savions qu’ils contenaient des dates ; ou qui, à  tout le moins,
était supposés en contenir ! Un tel champ de date pouvait-il contenir, par exemple,
la valeur 063198 ? Bien sûr. La seule réserve étant les programmes à  écrire pour
accéder au fichier et le fait que si notre contrôle de validité était laxiste
ou si quelqu’un se servait d’un utilitaire comme DFU pour entrer des données,
le champ pouvait contenir n’importe quoi. C’est pourquoi nous pouvions y placer
des zéros.

Avec des champs de type date, le système sait que les champs représentent plus
que de simples nombres. Ils ne peuvent contenir que des dates valides du 1er janvier
0001 au 31 décembre 9999. Même avec DFU ou avec la commande UPDDTA (Update Data),
il est impossible de placer une date erronée, contenant par exemple uniquement
des zéros (00/00/0000), dans un champ de type date, ce qui nous satisfait pleinement…
jusqu’à  ce que nous arrivions aux dates qui n’existent pas encore réellement.

On pourrait utiliser une valeur spéciale comme 01/01/0001 ou 31/12/9999 dans de
telles situations, mais, sur le plan technique et esthétique, cette solution laisse
quelque peu à  désirer. Faisons entrer en scène les dates nulles. Par définition,
null signifie absence de valeur, et donc il semble logique de l’utiliser pour
indiquer une date non encore connue.