"TIMESTAMP WITH TIME ZONE" <--> Il mapping DateTImeOffset non recapiterà la parte Zone nei comandi INSERT (Entity Framework + Oracle)

Question

Io uso EF (modello EDMX - DB prima) per mappare "TIMESTAMP WITH TIME ZONE" a DateTimeOffset. quando commetto DateTimeOffset su Oracle, la parte Zona viene salvata in modo errato.

Quindi, se si utilizza il modello, ad esempio, inserire il valore 29/02/2012 10:10:10 +04:00, il valore che viene in realtà memorizzati in Oracle è 29/02/2012 10:10:10 +02:00 (supponendo 02: 00 è orario locale) Nota che i mapping funziona bene quando si interroga il dati. Solo INSERT (via ObjectContext.SaveChanges()) è rotto ...

Ho eseguito il debug in "Oracle.DataAccess.dll" (utilizzando ILSpy :)) e ho scoperto che il codice di mapping per EF omette la zona ("Oracle Data Provider" passa solo DateTimeOffset.DateTime).

Qualcuno sa una soluzione?

Grazie in anticipo Eli

BTW: sto usando .net4, EF4, Oracle 11g, ODAC 11.2 di uscita 4 (11.2.0.3.0)

Answer 1

Si potrebbe provare a dynamicly set the Session Time Zone, che " ha effetto quando un valore TIMESTAMP viene convertito in TIMESTAMP WITH TIME ZONE o TIMESTAMP WITH LOCAL TIME ZONE datatype ".

... un attacco terribile, naturalmente, anche perché non è possibile eseguire alter sessioni direttamente tramite SQL. Dovreste usare qualcosa come

begin DBMS_UTITLITY.EXEC_DDL_STATEMENT ('Alter Session Set TIME_ZONE = ''+04:00'''); end; 

Answer 2

Oracle ha ammesso che questo era un bug https://community.oracle.com/thread/2360615?tstart=0. E triste che fosse stato risolto nel bug 13851978. Ma il mio test sul client Oracle su 11.2.0.3.0 è ancora fallito.

Sulla soluzione è come @HAL 9000 suggerito di impostare il fuso orario della sessione con le ore e i minuti nel periodo di tempo di DatetimeOffset prima di salvare nel database. Ma questo non funzionerà se ci sono più proprietà di DatetimeOffset in un oggetto e queste proprietà hanno tempi diversi in Datetimeoffset.

Un'altra alternativa è la sostituzione di ODP.NET con provider di dati di terze parti come DevCot DotConnect (l'ho provato, funziona per me). Esiste un confronto in StackOverflow su diversi fornitori di dati https://stackoverflow.com/a/8298684/1443505.

Answer 3

La memorizzazione di offset nel database potrebbe non essere valida per Gestione offset di risparmio diurno. È buona norma utilizzare sempre nomi di fuso orario su valori di offset in cui lo scopo non viene modificato.

--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'