Zumal die Zeitzone aktuell nur per Systemwert auslesbar ist.
Der Timestamp auf der IBM i ist immer localtime!
Um also die UTC-Zeit zu bekommen musst du eine external Function schreiben, die den aktuellen Offset aus dem Systemwert ausliest und die UTC dann ausrechnet.
Ggf. kannnst du so eine eigene Cast-Funktion schreiben, die das Ergebnis als CHAR-Feld zurückgibt.

Ich verstele den Hype um den Timestamp with Timezone sowieso nicht.
Wenn ich in der DB grundsätzlich UTC speichere, kann ich ja jederzeit den Timestamp mit "+00:00" ausgeben. Die Anzeige der Localtime ist ja sowieso immer Sache des Clients, da dessen Zeitzone für die Darstellung gilt. Es interessiert mich halt nicht, wie die Zeitzone mal war als die Zeit eingestellt wurde.

Ich habe mal für Infor-XPPS das Problem "mehrere Zeitzonen auf der IBM i" lösen müssen, was aktuell nur mit den C-UnixAPI's und den Locale-Einstellungen je Job funktioniert.
SQL und ILERPG interessieren sich dafür allerdings nicht.

Ach ja: Und das Problem der doppelten/fehlenden Zeiten für Differenzrechnung und Sortierungen bei der Zeitumstellung gibts bei Verwendung von UTC nicht.