Da man das mit der Zeitzone ja weiß, konnte man dies ja schon füher in der DB durchaus berücksichtigen, wenn diese Info benötigt wurde.
Ein Timestamp kann schon immer mittel QUTCOFFSET aus der Systemzeit die UTC-Zeit errechnen und in der DB speichern. Das geht nun mal nicht mit "current timestamp" per SQL oder %Timestamp().
Die jeweils aktuelle Zeitzone konnte man ebenso separat speichern.
Dies nun als spezielles Timestampwithzone-Feld zu entwickeln halte ich persönlich für nicht erforderlich, da es damit auch zu Inkompatibilitäten kommen kann.
Bei vernünftigem Design (wie Dieter immer schön sagt) hätte man das Problem nie gehabt;-).
Einfach nur UTC-Zeit sowie UTCOFFSET speichern und alles ist ok.
Auch mit %Minutes() und %Hours() lässt sich aus QUTC dann die UTC-Zeit errechnen

In Unix z.B. gibt die Zeitfunktion immer die Anzahl Sekunden seit 1.1.1970 in UTC zurück, also damals schon berücksichtigt.
Ich habe allerdings auch AS/400-Systeme gesehen wo QUTCOFFSET immer 00:00 war und die Systemzeit halt immer umgestellt wird. Da bring so ein Timezone-Timestamp nun auch nichts.

Hat SQL denn schon die Funktionen "LocalTime" oder UTCTime realisiert?
Kann die AS/400 ähm IBM i inzwischen mehrere Zeitzonen (ohne Aufwand) auf derselben Maschine?
Ich habe dies für Kunden schon realisieren müssen.