Das nacht einfach die Erfahrung;-). Und ich habe mir schon früher die Mühe genacht, den generierten MI-Code zu analysieren.
Und daher weiß ich, dass in den Tiefsten Schichten der Datenbank die Funktion QDBGET/QDBPUT aufgerufen werden. Und wenn ich eine Tabelle intern beschrieben einlese, werden mir wie beim DSPPFM de aufbereiteten Datum/Zeit und Zeitmarkenfelder übergeben. Da spielt die RPG-Runtime noch gar keine Rolle.
Zum Vergleich: COBOL nutzt auch bei ILE die nativen Datenpuffer der File-Controlblocks. Und da ist von scaliger Nummern auch nichts zu sehen.

Aber viel wichtiger ist doch, was am Ende rauskommt.
Und da entscheiden die Definitionen der RPG-Felder, die durhch H-Bestimmung und Option-Statement die Formate festlegen.
Was die Datumskonvertierungen angeht, so liegen diese schon früher in den nativen MI-Befehlen, die von der RPG-Runtime halt nur mit verwendet werden.
Deshalb gibts auch MCH- und keine RPG-Fehler.

https://www.ibm.com/docs/en/i/7.4?to...hine-interface
Z.B.:
https://www.ibm.com/docs/en/i/7.4?to...vert-date-cvtd

Somit gibt es mehrere MI-Befehle, die für Konvertierungen und Berechnungen zur Verfügung stehen. Warum sollte sich eine Runtime darüber Gedanken machen und das Rad neu erfinden?
Ich habe sogar einen MI-Compiler geschrieben, mit dem man all die schönen Dinge komfortabel programmierren kann.