Inconsistent results with localtimestamp and current_timestamp

Question

Running XE on Windows XP with the system timezone to GMT rebooted, restarted XE)
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE     10.2.0.1.0     Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
I'm getting incorrect and inconsistent results with current_timestamp and localtimestamp:
With SQL, localtimestamp computes the wrong offset (appears to use 1987-2006 DST rules):
select
dbtimezone
, sessiontimezone
, current_timestamp
, current_timestamp + numtodsinterval(18,'day') as current_timestamp18
, localtimestamp
from dual;
+00:00     
US/Eastern     
17-MAR-10 10.27.17.376000000 AM US/EASTERN     
04-APR-10 10.27.17.376000000 AM US/EASTERN     
17-MAR-10 09.27.17.376000000 AM
however, in PL/SQL, both current_timestamp and localtimestamp return the wrong hour value, and adding 18 to current_timestamp shows it is using 1987-2006 DST rules (1st sunday of april)/ note that this happens in straight PL/SQL and in embedded SQL (same results selecting from tables other than DUAL):
begin
for r1 in (
select
dbtimezone
, sessiontimezone
, current_timestamp
, current_timestamp + numtodsinterval(18,'day') as current_timestamp18
, localtimestamp
from dual
loop
dbms_output.put_line('SQL dbtimezone = ' || r1.dbtimezone);
dbms_output.put_line('SQL sessiontimezone = ' || r1.sessiontimezone);
dbms_output.put_line('SQL current_timestamp = ' || r1.current_timestamp);
dbms_output.put_line('SQL current_timestamp +18 = ' || r1.current_timestamp18);
dbms_output.put_line('SQL localtimestamp = ' || r1.localtimestamp);
end loop;
dbms_output.put_line('dbtimezone = ' || dbtimezone);
dbms_output.put_line('sessiontimezone = ' || sessiontimezone);
dbms_output.put_line('systimestamp = ' || systimestamp);
dbms_output.put_line('current_timestamp = ' || current_timestamp);
dbms_output.put_line('current_timestamp +18 = ' || (current_timestamp + numtodsinterval(18,'day')));
dbms_output.put_line('localtimestamp = ' || localtimestamp);
end;
SQL dbtimezone = +00:00
SQL sessiontimezone = US/Eastern
SQL current_timestamp = 17-MAR-10 09.29.32.784000 AM US/EASTERN
SQL current_timestamp +18 = 04-APR-10 10.29.32.784000000 AM US/EASTERN
SQL localtimestamp = 17-MAR-10 09.29.32.784000 AM
dbtimezone = +00:00
sessiontimezone = US/Eastern
systimestamp = 17-MAR-10 02.29.32.784000000 PM +00:00
current_timestamp = 17-MAR-10 09.29.32.784000000 AM US/EASTERN
current_timestamp +18 = 04-APR-10 10.29.32.784000000 AM US/EASTERN
localtimestamp = 17-MAR-10 09.29.32.784000000 AM
dbtimezone = +00:00
sessiontimezone = US/Eastern
systimestamp = 17-MAR-10 02.16.21.366000000 PM +00:00
current_timestamp = 17-MAR-10 09.16.21.366000000 AM US/EASTERN
current_timestamp +18 = 04-APR-10 10.16.21.366000000 AM US/EASTERN
localtimestamp = 17-MAR-10 09.16.21.366000000 AM
is this a known bug?
is there a patch or a work-around for XE?
are other datasbase versions affected?

Answer 1

Can't patch XE, unfortunately it comes with pre-2007 DST rules.
There is a metalink note describing how to fix the DST changes, and while it's not really a "supported" method, neither is XE- if you can get updated timezone files from a later patch set for the same release, 10gR2, on the right operating system, shutdown/startup the database the updated DST rules will be in place. The timezone files are in $ORACLE_HOME/oracore/zoneinfo.
Another unfortunately, any values already stored in the database using timestamp with local timezone datatypes for the affected period of the DST changes won't be correct, i.e. there is no 2010-03-14 02:01 (?) but with older timezone rules in place that would be a valid timestamp. The data has to be saved before updating the timezone file, and re-translated to timestamp w/local tz datatypes after the update.
IMHO storing literal timezone info isn't an ideal practice, let the client settings do the time interpretation, time is always changing. Its the interpretation of the time that gets changed. From time to time. :(