TIMESTAMP WITH TIME ZONE ‹--› Сопоставление DateTImeOffset не будет доставлять часть зоны в командах INSERT (Entity Framework + Oracle)

Я использую EF (модель EDMX — сначала БД), чтобы сопоставить «TIMESTAMP WITH TIME ZONE» с DateTimeOffset. когда я передаю DateTimeOffset в Oracle, часть зоны сохраняется неправильно.

Таким образом, при использовании модели, например, для вставки значения 29/02/2012 10:10:10 +04:00 значение, которое фактически хранится в Oracle, равно 29/02/2012 10:10:10 +02:00 (при условии, что +02:00 является локальной зоной). Обратите внимание, что сопоставления работают очень хорошо при запросе данных. Не работает только INSERT (через ObjectContext.SaveChanges())...

Я выполнил отладку в «Oracle.DataAccess.dll» (используя ILSpy :)) и обнаружил, что код сопоставления для EF пропускает зону («Поставщик данных Oracle» передает только DateTimeOffset.DateTime).

Кто-нибудь знает обходной путь?

Заранее спасибо Эли

Кстати: я использую .net4, EF4, Oracle 11g, ODAC 11.2 Release 4 (11.2.0.3.0)


entity-framework oracle timestamp datetimeoffset zone
person EliH    schedule 02.03.2012    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Вы можете попытаться динамически установить часовой пояс сеанса, который «вступает в силу, когда значение TIMESTAMP преобразуется в тип данных TIMESTAMP WITH TIME ZONE или TIMESTAMP WITH LOCAL TIME ZONE».

... ужасный взлом, конечно, еще и потому, что вы не можете выполнить изменение сеанса напрямую через SQL. Вам нужно будет использовать что-то вроде

begin DBMS_UTITLITY.EXEC_DDL_STATEMENT ('Alter Session Set TIME_ZONE = ''+04:00'''); end;
person HAL 9000    schedule 12.03.2012

arrow_upward
0
arrow_downward

Oracle признал, что это ошибка https://community.oracle.com/thread/2360615?tstart=0. И они сожалеют, что это было исправлено в ошибке 13851978. Но мой тест на клиенте оракула на 11.2.0.3.0 все еще не удался.

В решении @HAL 9000 предложил установить часовой пояс сеанса с часами и минутами в промежутке времени DatetimeOffset перед сохранением в базе данных. Но это не сработает, если в одном объекте есть несколько свойств DatetimeOffset, и эти свойства имеют разные промежутки времени внутри Datetimeoffset.

Другой альтернативой является замена ODP.NET сторонним поставщиком данных, таким как DotConnect от Devart (я проверял это, у меня это работает). В stackoverflow есть сравнение разных поставщиков данных https://stackoverflow.com/a/8298684/1443505.

person ivenxu    schedule 26.04.2014

arrow_upward
0
arrow_downward

Хранение смещений в базе данных может не подходить для управления смещением летнего времени. Хорошей практикой будет всегда использовать имена часовых поясов вместо значений смещения, если это не влияет на цель.

--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'
person Varun Rao    schedule 01.01.2015