Поле даты Oracle - проблемы времени - PullRequest
2 голосов
/ 25 августа 2009

У нас есть две базы данных в двух разных местах. Одна из баз данных находится в отдельном часовом поясе, чем наши пользователи.

Проблема в том, что при обновлении базы данных, расположенной в отдельном часовом поясе, со значением даты, база данных автоматически вычитает 1 час из даты, когда она была передана.

Проблема заключается в том, что при передаче значения NULL (12:00:00) значение DAY изменяется на предыдущий день.

Обновления выполняются с помощью хранимых процедур, а интерфейс - это смарт-клиент VB.NET.

Как бы вы справились с этим правильно? Я вообще не хочу хранить ВРЕМЯ вообще, но я не могу понять, как это сделать.

Ответы [ 3 ]

2 голосов
/ 26 августа 2009

Непонятно, в какое время суток вы хотите включить в базу данных или что передает приложение.

Предположим, что пользовательский компьютер сообщает ему, что сейчас вторник, 12:30, а часы на сервере Db показывают понедельник, 11:30.

Если вы вставите значение для «текущей даты» (например, TRUNC (SYSDATE)), то для базы данных это все еще понедельник. Если вы вставите значение для текущего времени (например, SYSDATE), это также будет понедельник. если вы вставите значение для текущего времени сеанса (например, CURRENT_TIMESTAMP) и часового пояса и попросите базу данных сохранить его в базе данных, оно сохранится в 23:30. Если вы попросите базу данных сохранить дату и время «2009-12-31 14:00:00», то это то, что она будет хранить. Если вы попросите сохранить дату / время в часовом поясе '2009-12-31 14:00:00 +08: 00', то вы находитесь в расширенном руководстве. Вы можете попросить базу данных хранить временные метки с данными часового пояса . Также рассмотрим летнее

1 голос
/ 01 декабря 2009

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

По моему мнению, данные даты и времени могут и всегда должны храниться в UTC. Эти данные могут быть преобразованы в местное время в том месте, где они представлены пользователю. Oracle на самом деле делает это легко с TIMESTAMP с типом данных TIME ZONE. Он позволяет получить доступ к данным как в формате UTC (SYS_EXTRACT_UTC), так и в качестве местного времени (локально для сервера базы данных.)

Во всех точках мира никогда не бывает одинакового дня, поэтому даты нельзя рассматривать без времени.

Конечно, другое мое мнение заключается в том, что переход на летнее время следует исключить. Но это уже другая тема.

1 голос
/ 26 августа 2009

Я бы исследовал использование функции TRUNC в вашем хранимом методе proc, который обновляет таблицу. Если тип данных в методе (который обновляет таблицу) не является типом DATE, тогда используйте функцию to_date вместе с функцией TRUNC.

...