I've just looked into this and confirmed this to be true - which is quite a shock. There was a point in time when the column was correctly being created as a TIMESTAMP. Therefore I think a bug was introduced somewhere in our release cycle which caused DATEs to be used instead.
I am filing a P1 bug to get this resolved for future releases. There will also be an upgrade task to fix current installations.
In the meantime a manual remedy is quite simple - you can issue an ALTER STATEMENT to modify the column back to timestamp.
Please let me know if this works.
Thanks Mark. That is great to know that it is in fact a bug and not a forced feature to have the dates. Since I posted I did go ahead and test the approach of forcing the a creation_ts column to timestamp in Oracle and then generated some test data and reran the ETL and it came over correctly (sample below).
GROUP_NAME CREATION_DATE MODIFICATION_DATE
1002 0 TestETLGroup2 19-MAR-10 03.34.55.267000000 PM 19-MAR-10
1001 0 TestETLTimestampGroup 19-MAR-10 03.29.08.406000000 PM 19-MAR-10
I left modification_date as date and altered creation_date as timestamp and it came over correctly.
Thanks for the quick response and pushing this one to get a fix in.
I will modify the columns as a workaround in our dev environment but I would be hesitant to run alter table commands in an environments above that, so I will keep an eye out for the upgrade task.