SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI')
,TO_CHAR(CURRENT_DATE, 'YYYY-MM-DD HH24:MI')
,TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI TZR')
,TO_CHAR(CURRENT_TIMESTAMP, 'YYYY-MM-DD HH24:MI TZR')
,TO_CHAR(LOCALTIMESTAMP, 'YYYY-MM-DD HH24:MI TZR')
,DBTIMEZONE
,SESSIONTIMEZONE
FROM DUAL;
Is returning:
2012-01-16 11:42
2012-01-16 11:42
2012-01-16 11:42 -06:00
2012-01-16 11:42 -06:00
2012-01-16 11:42 +00:00
+00:00
-06:00
It seems to think the database time zone is GMT, yet the SYSDATE is the same as the CURRENT_DATE.
When I remote into that server (Windows), the time zone is apparently CST (however, I am aware that this could be picking up my Terminal Services Client Time Zone Offset, but this machine doesn't have Terminal Services on it, just administrative)
Running the same thing against a server in Amsterdam (4 minutes later all from the same TOAD client), I'm getting:
2012-01-16 18:46
2012-01-16 11:46
2012-01-16 18:46 +01:00
2012-01-16 11:46 -06:00
2012-01-16 11:46 +00:00
+02:00
-06:00
Note the +2, but at least the SYSDATE and CURRENT_DATE are differing.
What is going on here? Where does SYSDATE come from and is there anything else which affects it?
It seems like DBTIMEZONE is not used for any of these things? So what is DBTIMEZONE used for?