You have a misconception about the "current timestamp" in a SQL statement...
Each SQL statement is executed at a single point in time only and the duration of the execution is not relevant. That means, whenever a SQL statement starts executing, it grabs the current timestamp value and "freezes" that for its own execution. Thus, the timestamps in a before and after trigger are always the same because triggers are compiled into the INSERT statement and, therefore, use the same frozen current timestamp.
Here is an example that you can try yourself:
Code:
$ db2 "create table t ( a int, before timestamp )"
DB20000I The SQL command completed successfully.
$ db2 "create trigger b before insert on t referencing new as n for eachrow set n.before = current timestamp"
DB20000I The SQL command completed successfully.
$ db2 "create table t2 ( after timestamp )"
DB20000I The SQL command completed successfully.
$ db2 "create trigger a after insert on t for each row insert into t2 values ( current timestamp )"
DB20000I The SQL command completed successfully.
$ db2 "insert into t(a) values ( 1 )"
DB20000I The SQL command completed successfully.
$ db2 "select * from t"
A BEFORE
----------- --------------------------
1 2008-07-16-08.52.26.528022
1 record(s) selected.
$ db2 "select * from t2"
AFTER
--------------------------
2008-07-16-08.52.26.528022
1 record(s) selected.
This is standard SQL behavior, and it makes perfect sense because each SQL statement is supposed to be "atomic". And having a duration for atomic operations is a bit counter-intuitive. Granted, it is impossible to execute statements without any duration, but conceptually it is possible to give applications such a view and that is what's done.
If you need the real timestamp when the statement completed, you have to resort to some external facility to determine the timestamp, e.g. use a UDF to retrieve the information from an independent facility like the operating system. But note that "statement completed" is not really true there either. The trigger calling the UDF is executed as part of the INSERT statement, so the execution is not really completed yet.