I've been slowly exploring adapting TIMESTAMP WITH TIME ZONE with our product and tonight did an initial test ALTERing a number of existing TIMESTAMP columns over. Our product immediately failed with the following error: Cannot convert timestamp with time zone to a numeric The SQL behind it appears to be: "select max(LastChanged) from dba.LocalSettings" This command succeeds if I substitute "cast(LastChanged as timestamp)" but that kinda defeats the purpose. Is this intentional? The help files seem rather silent on how operations that succeed on timestamps would fail on timestamp-with-time-zone, some places even suggest that it would degrade to a simple timestamp when necessary. If timestamp-with-time-zone is such a different animal from simple-timestamp then this is going to be a much more painful migration... select @@version == 12.0.1.3406 |
This issue was fixed last November in 12.0.1.3504
You will need to download and apply a recent EBF. figures, thanks for the fast grep of the ChangeLog. Will try to do something later this week, hopefully I can disable enough stuff prevent a forced reboot.
(01 Feb '12, 23:32)
Erik Anderson
|