My database was configured with an dbtimezone=+2:00:
When my application sends a date which has a timezone, does Oracle automatically translate the date to its dbtimezone and store it in the column?
When my application asks for a field date, does Oracle automatically translate it to the application timezone?
In order to be consistency with business rules, I wanted to change this dbtimezone to UTC. So I made the alter database set time_zone='UTC' command, I restarted the oracle server and now the select dbtimezone from dual; command returns "UTC".
But, all fields date in DB haven't changed (no change -2 hours from GMT+2 to UTC). When I ask the sysdate, it returns the GMT+2 date ... I try to change my SQL Developer configuration timezone to UTC but it didn't change anything. Do I have an issue of Oracle session parameters that convert my DB data to GMT+2 before displaying it ?
Finally, does anyone have a good practice to make this change ? (change the database timezone and existing date to a new timezone).
If all you're doing is changing the database time zone setting, then you are only going to notice any change in output if your data is stored with the TIMESTAMP WITH LOCAL TIME ZONE type.
I don't recommend that though. It would be much better if your data was just stored in a regular TIMESTAMP field and was already set to UTC.
You should read the documentation about all of the different date and time datatypes, so you understand how each of these types works and differs from the other.
Related
Currently, I am working on migrating an Oracle database schema to Postgres. As part of it I have to convert a custom utility function in Oracle which generates timestamps based on timezone. But the values obtained from Oracle and Postgres seem to vary by one hour.
Oracle:
SELECT (to_timestamp_tz('20300714 235959 CET','YYYYMMDD HH24MISS TZR') - to_timestamp_tz('19700101 000000 GMT','YYYYMMDD HH24MISS TZR'))
as foo FROM dual;
yields +22109 21:59:59.000000
Postgres:
select ('20300714 235959'::timestamp AT TIME ZONE 'CET') - ('19700101 000000'::timestamp AT TIME ZONE 'GMT') as foo;
yields 22109 days 22:59:59
I guess the reason for this difference is because of daylight saving but I am not sure. Can anyone help me out with this problem.
I am using Postgres v9.6 and Oracle 12c.
Well, I found the mistake I was doing. Postgres seems to handle the abbreviated timezone name and full timezone name differently. In case if you want to incorporate daylight related changes you would have to use full timezone name. In my case using 'Europe/Amsterdam' instead of 'CET' yielded the same result as that of Oracle.
To find the complete list of full timezone names supported by Postgres, I used the query:
select * from pg_timezone_names where abbrev='CET';
I am new to SQL developer but each time i get queries it changes time stamp to readable date format, but i want my result to be in time stamps as they are in database.
Please go to: Tools/Preferences/Database/NLS and set there date format and timestamp format to what you want.
Oracle stores date and timestamp type but display it according to NLS settings. You either call alter session set NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH:MI:SS.FF'; or just set those NLS settings in your client tool.
Documentation
I have some data that is stored in a TIMESTAMP(6) WITH TIMEZONE column in Oracle, but it is stored in the wrong timezone. By convention, all timestamps in the DB must be stored in UTC, but this data was incorrectly persisted as EDT. The actual values are equivalent to the correct UTC value; the problem is simply that it is stored as 19-JUN-12 12.20.42.000000000 PM AMERICA/NEW_YORK when instead it should be 19-JUN-12 16.20.42.000000000 PM UTC. Is there any way in Oracle to change this?
Do you really need to change the data that is stored in the database? Normally, it's sufficient just to convert to a different time zone for display, i.e.
SELECT <<your_timestamp_column>> AT TIME ZONE 'UTC'
FROM <<your table>>
Of course, if you want to, you can also
UPDATE <<your table>>
SET <<your timestamp column>> = <<your timestamp column>> AT TIME ZONE 'UTC'
to change all the data.
I use EF (EDMX model - DB first) to map "TIMESTAMP WITH TIME ZONE" to a DateTimeOffset. when I commit the DateTimeOffset to Oracle, the Zone part is saved incorrectly.
So if using the model, for example, to insert the value 29/02/2012 10:10:10 +04:00, the value that is actually stored in Oracle is 29/02/2012 10:10:10 +02:00 (assuming +02:00 is local zone)
Note that the mappings works just fine when querying the data. Only INSERT (via ObjectContext.SaveChanges()) is broken...
I've debugged into the "Oracle.DataAccess.dll" ( using ILSpy :) ) and found that the mapping code for EF omits the zone (the "Oracle Data Provider" passes the DateTimeOffset.DateTime only).
Does anyone know a workaround?
Thanks in advance
Eli
BTW: I am using .net4, EF4, Oracle 11g, ODAC 11.2 Release 4 (11.2.0.3.0)
You could try to dynamicly set the Session Time Zone, which "takes effect when a TIMESTAMP value is converted to the TIMESTAMP WITH
TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE datatype".
...a terrible hack of course, also because you cannot execute alter session directly through SQL. You'd have to use something like
begin DBMS_UTITLITY.EXEC_DDL_STATEMENT ('Alter Session Set TIME_ZONE = ''+04:00'''); end;
Oracle admitted this was a bug https://community.oracle.com/thread/2360615?tstart=0. And they sad it had been fixed in bug 13851978. But my test on oracle client on 11.2.0.3.0 is still failed.
On solution is as #HAL 9000 suggested setting the session's time zone with the hours and minutes in time span of DatetimeOffset before saving to database. But this won't work if there are multiple DatetimeOffset properties in one object and these properties have different timespans inside Datetimeoffset.
Another alternative is replacing ODP.NET with 3rd-party data provider such as Devart's DotConnect(I've tested this, it works for me). There is a comparison in stackoverflow about different data providers https://stackoverflow.com/a/8298684/1443505.
Storing offsets in the database might not hold good for Daylight savings offset Management.
It will be a good practice to always use timezone names over offset values where the purpose is unaffected.
--To store actual time and timezone value
to_timestamp_tz('10-SEP-2014 01:40:00.000000000 US/Pacific','DD-MON-YYYY HH24:MI:SS.FF9 TZR')
--To store actual time at timezone converted to UTC timezone value for uniformity
to_timestamp_tz('10-SEP-2014 01:40:00.000000000 US/Pacific','DD-MON-YYYY HH24:MI:SS.FF9 TZR') at time zone 'UTC'
I am hitting a bit of a problem when using the date datatype. When trying to save a row to the table where the field it throws an error ora 01830 and complains about converting the date format picture ends...etc. Now when I do the insert, I use the to_date function with the format of "dd-mon-yyyy hh24:mi:ss". Of course, when I remove the time element, everything is perfect.
Checking sysdate, I noticed that the time element wasn't be displayed, and I used alter session set nls_date_format to set the date and time I want to save to the table, which worked!
I used alter system set nls_date_format ="dd-mon-yyyy hh24:mi:ss" scope=spfile; This showed that it was altered, and I can see the setting in the enterprise management console. In sqlplus, I shutdown the database, and restarted with startup mount; alter database open; and then selecting sysdate, it still shows the date as dd-mon-yy, and still no time! Checking the enterprise management, and looking up the nls_date_format the setting is still shown as "dd-mon-yyyy hh24:mi:ss".
So, my question is this - what am I doing wrong? Why can't save date and time using date in Oracle 11g?????
Thanks
Dates are stored with "second" granularity in Oracle.
Display formats are dependent on the system and session. In your case, since you are connecting with sqlplus, you are using a default session format from the client that does not include time. You need to execute an:
ALTER SESSION SET nls_date_format ="dd-mon-yyyy hh24:mi:ss";
when you start up your sqlplus client in order to change the default display. There is a client side file (glogin.sql?) that sqlplus will run on startup. You can place this kind of command in there if you want it to be executed each you start that client. I'm pretty sure the sqlplus client sends an "alter session set nls_date..." on start up.
In general, when outputting dates, I think it is better to just be explicit on the format by doing a TO_CHAR(myDateColumn, "dd-mon-yyyy hh24:mi:ss"). If you are reading dates programatically, you don't need to worry about it since you are dealing with internal formats, not display formats.
I've seen this error when the input data did not match the date format used. check your, data would be my suggestion.