Man kann sich ja schön per DSPFFD ansehen, dass mit der Pufferposition und Länge das Feld bereits aufbereitet geliefert bzw. erwartet wird.
DSPFFD bereitet das so auf und kommt noch aus der "alten" Zeit, als das Format im DDS nur dazu verwendet wurde um das Datum in WRKF lesbar zu machen.

Hast Du Dir zufällig mal die Mühe gemacht die Definition von Datums-Feldern in der Catalogview SYSCOLUMNS anzuschauen?
Storage ist 4Byte und nicht 10 Bytes. Die Informationen in der Catalog View kommen übrigens direkt aus der original "Datenbanken-"Datei QADBIFLD und in dieser Datei ist nirgends eine Länge von 10 für Datumsfelder zu finden.

Oder hast Du Dir vielleicht zufällig mal den Hex-Wert eines Datums angeschaut?
Das ist die Scaliger Nr und hat nichts mit irgendeiner aufbereiteten Datums-Format-Representation zu tun. Hex-Value für das heutige Datum ist z.B. 00257D80 (genau 4 Byte und genau so steht es in der Datei)
Ändere das Datums-Format in Deinem Job und die Datumsfelder werden in diesem Format angezeigt. Datumsfelder, die außerhalb des gültigen Bereichs für die Anzeige liegen, werden mit einer Anzahl von Plus-Zeichen angezeigt.
Der Hex-Wert ist jedoch immer noch der gleiche!
Es ist sogar möglich gültige Datumswerte, die außerhalb des gültigen Anzeige-Bereichs liegen einzufügen.
Die Konvertierung erfolgt direkt beim Schreiben (DDS wie SQL).
Ein "falsches" Datum kann nicht konvertiert werden, was bedeutet, dass auch in DDS kein falsches Datum eingefügt werden kann.

Birgitta