Home » SQL & PL/SQL » SQL & PL/SQL » correct treatment of date across different timezones (Oracle 19)
correct treatment of date across different timezones [message #689733] |
Thu, 04 April 2024 03:19 |
|
jansulc
Messages: 4 Registered: April 2024
|
Junior Member |
|
|
Hello all.
we have a database, until now located in Germany
another database, also located in Germany, is sending data to us, and inserts some additional status info into our table (over db link)
something like:
insert into status_table (name_of_delivery, status_flag, insertion_date)
values ('Delivery ABC', 'Transfer finished', sysdate);
now we moved to Oracle 19, located in London
which caused big trouble, since the "sysdate" inserted is now false, it is one hour ahead (since Germany has 1+ against London)
question 1
how should they (German database) change their insert statement?
something like this?
first, find out what time it is, in the target database:
SELECT CAST((CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London') AS DATE) dt from dual;
...and then use it instead of "sysdate" in their insert stmt?
question 2
is it possible / advisable to use more general/dynamic approach?
the solution above relies on the fact, that target database team always informs all other database teams about change of location, and they change their code
wouldn't it be better, if:
database, which sends "sysdate" via db-link into other database, always uses more "sofisticated" code, which:
1. finds out the target db timezone - select dbtimezone from dual@remote_db
2. combines this dbtimezone value with the sysdate and uses this value in the "insert statement"
Then, even if the target database moves to different location, and they forget to inform other teams about it, everything works fine for everybody, without a need to change any code, right?
question 3
if my idea above is correct, can you please give me some hints what syntax to use?
so far I discovered this possibility:
with t1(tm) as
(select systimestamp from dual
)
select tm as timedate_with_diff_against_UTC
,cast(to_timestamp_tz(tm, 'dd-mon-yy hh24.mi.ss.ff TZH:TZM') as date) as into_date
,(select dbtimezone from dual) as diff_against_GMT
--dbtimezone info is selected from remote/target db:
,cast(to_timestamp_tz(tm, 'dd-mon-yy hh24.mi.ss.ff TZH:TZM') at time zone ((select dbtimezone from dual)-(select dbtimezone from dual@remote_db))
as date) as dynamic_TZ
from t1;
But:
- if I am correct, systimestamp shows shift against UTC
UTC is used by nobody, is does not reflect summer time shifts.
- better is "dbtimezone" info - it reflects also summer time
- my idea is: select our local dbtimezone, substract it from target database dbtimezone and use the value in the "at time zone" clause
But is it good idea to do such a substraction?
Like the one above:
(select dbtimezone from dual)-(select dbtimezone from dual@remote_db)
(...but, it cannot be done exactly like this, it creates issue with NUMBER/CHAR inconsistent datatypes.
Don't know if this a right direction - if yes, I will try to solve this datatype issue.)
I think there must be some general solution, some "good practice" way, how to manage this, but couldn't find any in the documentation.
Thanks for any hint.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Thu Nov 21 08:21:04 CST 2024
|