Dbtimezone oracle на что влияет

Обновлено: 02.07.2024

Кажется, что часовой пояс базы данных GMT, но SYSDATE совпадает с CURRENT_DATE.

Когда я удаляюсь на этот сервер (Windows), часовым поясом, по-видимому, является CST (однако я знаю, что это может быть связано с отключением часового пояса клиента служб терминалов, но на этом компьютере нет служб терминалов, просто административный)

Запустив то же самое на сервере в Амстердаме (через 4 минуты все от одного и того же клиента TOAD), я получаю:

Обратите внимание на +2, но по крайней мере SYSDATE и CURRENT_DATE отличаются.

Что здесь происходит? Откуда появляется SYSDATE и есть ли что-нибудь еще, что влияет на него?

Кажется, что DBTIMEZONE не используется ни для одной из этих вещей? Итак, для чего используется DBTIMEZONE?

спросил(а) 2012-01-16T21:26:00+04:00 9 лет, 10 месяцев назад

На самом деле есть 3 часовых пояса, а не 2

    часовой пояс сеанса/клиента
      Показан в SESSIONTIMEZONE
      Это часовой пояс CURRENT_DATE, LOCALTIMESTAMP и CURRENT_TIMESTAMP. Разница между ними - тип возврата, они возвращают DATE, TIMESTAMP и TIMESTAMP WITH TIME ZONE соответственно).
      Отображается в DBTIMEZONE
      Это часовой пояс, используемый для внутреннего хранения значений TIMESTAMP WITH LOCAL TIME ZONE. Обратите внимание, что значения преобразуются в/из временной зоны сеанса в insert/select, поэтому на самом деле это не так важно, как кажется.
      Это не часовой пояс SYSDATE/SYSTIMESTAMP
      В unix он основан на переменной TZ при запуске Oracle.
      Это часовой пояс SYSDATE и SYSTIMESTAMP

    В первом примере я вижу, что сеанс TZ - UTC-6, база данных TZ - UTC, а часовой пояс базы данных - UTC-6.

    В вашем втором примере я вижу, что сеанс TZ - UTC-6, база данных TZ - UTC + 2, а часовой пояс базы данных - UTC + 1.

    Подробности приведены в мелкой печати документации. Взгляните на тип возвращаемого значения, и рассчитывается фактический часовой пояс DATE или TIMESTAMP.

      SYSDATE
        Тип возврата: DATE
        Часовой пояс: хост-сервер сервера баз данных
        Тип возврата: DATE
        Часовой пояс: сеанс
        Тип возврата: TIMESTAMP WITH TIME ZONE
        Часовой пояс: хост-сервер сервера баз данных
        Тип возврата: TIMESTAMP WITH TIME ZONE
        Часовой пояс: сеанс
        Тип возврата: TIMESTAMP
        Часовой пояс: сеанс
        Часовой пояс: временная зона DB. Наследуется от операционной системы сервера БД, но может быть переопределено с помощью набора в БД Создание или Изменение с использованием параметра TIME_ZONE DB (SET TIME_ZONE =. ). Это влияет на часовой пояс, используемый для типов данных TIMESTAMP WITH LOCAL TIME ZONE.
        Часовой пояс: Часовой пояс сеанса. Наследует ОС Session Host, но может быть переопределен с помощью ALTER SESSION (ALTER SESSION SET TIME_ZONE =. ).

      Возвращает тип, указывает, доступен ли Часовой пояс в этом типе данных. Если вы попытаетесь напечатать TZR, если тип данных не переносит TimeZone, тогда он будет отображаться как +00: 00 (не означает, что это GMT). В противном случае он отобразит TimeZone, соответствующий либо базе данных, либо сеансу, как указано.

      Часовой пояс, указывает, в какой временной зоне рассчитывается время. Для сопоставления TimeZone будет показана та же дата/время (HH24: MI).

      Обратите внимание, что ни одна из FUNCTIONS не возвращает TIME в часовом поясе, заданном с помощью DB TIME_ZONE (или возвратом функции DBTIMEZONE). То есть, ни одна из функций не возвращает тип данных TIMESTAMP с зоной локального времени. Как вы можете преобразовать вывод любой из функций, которые возвращают часовой пояс в другой часовой пояс (включая DBTIMEZONE) следующим образом:

      4 ответа

      Я решил эту проблему, используя следующую команду: «Выбрать системную метку для часового пояса« GMT »из DUAL». Эта команда всегда будет указывать дату и время по Гринвичу независимо от времени ОС.

      На одном из серверов баз данных Oracle он показывает «+01: 00», когда я запускаю «Select dbtimezone from dual», означает ли это, что летом часы будут переведены на один час вперед?

      Это означает, что часовой пояс вашей базы данных равен +01:00 по сравнению с часовым поясом UTC .

      DBTIMEZONE возвращает значение часового пояса базы данных. Тип возвращаемого значения - смещение часового пояса (тип символа в формате '[+ | -] TZH: TZM') или имя региона часового пояса, в зависимости от того, как пользователь указал значение часового пояса базы данных в последнем CREATE DATABASE. или оператор ALTER DATABASE.

      Итак, база данных DBTIMEZONE наследует значение часового пояса от ОС сервера БД .

      Хотя SESSIONTIMEZONE может быть переопределен на уровне сеанса оператором alter session.

      Это изменяет часовой пояс TIMESTAMP WITH LOCAL TIME ZONE .

      На другом сервере отображается «+00: 00». Означает ли это, что настройка сервера базы данных - GMT?

      +00:00 можно предположить, что часовой пояс базы данных установлен на часовой пояс UTC .

      Дополнительные сведения см. В документации.

      Ответ: это зависит от обстоятельств.

      Всего в вашей базе данных есть три часовых пояса.

      Часовой пояс вашего сеанса: SESSIONTIMEZONE

      Это вы можете изменить с помощью ALTER SESSION SET TIME_ZONE=. в любое время. Это актуально для результата

      • CURRENT_DATE
      • LOCALTIMESTAMP
      • CURRENT_TIMESTAMP

      Это также целевой часовой пояс, когда вы делаете CAST( AS TIMESTAMP WITH TIME ZONE)

      По умолчанию SESSIONTIMEZONE может быть задано переменной среды ORA_SDTZ или (в Windows) записью реестра HKLM\SOFTWARE\Wow6432Node\ORACLE\KEY_%ORACLE_HOME_NAME%\ORA_SDTZ (для 32-битного клиента), соответственно. HKLM\SOFTWARE\ORACLE\KEY_%ORACLE_HOME_NAME%\ORA_SDTZ (для 64-битного клиента).

      Часовой пояс базы данных: DBTIMEZONE

      На самом деле при повседневном использовании это не так важно, это актуально только для столбцов с типом данных TIMESTAMP WITH LOCAL TIME ZONE и определяет формат хранения.

      Это НЕ часовой пояс SYSDATE или SYSTIMESTAMP .

      Вы не можете изменить DBTIMEZONE в своей базе данных, если база данных содержит таблицу со столбцом TIMESTAMP WITH LOCAL TIME ZONE и этот столбец содержит данные. В противном случае его можно изменить с помощью ALTER DATABASE SET TIME_ZONE='. '; . Изменение не вступит в силу, пока база данных не будет выключена и перезапущена.

      DBTIMEZONE устанавливается при создании базы данных. Если во время создания базы данных часовой пояс не указан, Oracle по умолчанию использует часовой пояс операционной системы сервера.

      Часовой пояс операционной системы сервера баз данных:

      Этот часовой пояс актуален для результата

      Естественно, этот часовой пояс нельзя изменить на уровне базы данных. Если в вашей стране используется летнее время, этот часовой пояс может меняться дважды в год. Вы можете допросить его, например, с помощью SELECT TO_CHAR(SYSTIMESTAMP, 'tzr') FROM dual; .

      Итак, если ваша ОС сервера БД настроена правильно, то со следующей недели вы должны получить летнее время (по крайней мере, для Европы)

      Кроме получения смещения сеанса timezone и смещения базы данных timezone, существует ли какое-либо другое использование/роль SESSIONTIMEZONE и DBTIMEZONE в базе данных oracle.

      Я хочу знать, каковы последствия изменения значений SESSIONTIMEZONE и DBTIMEZONE с точки зрения вставки/извлечения дат в/из базы данных.

      2 ответа

      Какая польза от System.in.read() в java? Пожалуйста, объясните это.

      Есть ли в Oracle плавный способ получить числовую разницу между SESSIONTIMEZONE и DBTIMEZONE в текущий момент (когда я выполняю вызов)? Например: SELECT SESSIONTIMEZONE, DBTIMEZONE FROM DUAL; Возвращается: +04:00 +07:00 Итак, мне нужна какая-то функция, вызывая которую с заданными параметрами, я.

      В этих функциях используются часовые пояса сеанса и БД.
      - systimestamp timestamp в dbtimezone.
      - current_timestamp timestamp в sessiontimezone.

      И, вероятно, во многих других местах. Я уверен, что это изменение повлияет на dbms_scheduler.
      Oracle также использует сеанс timezone во время неявного преобразования из datetime без timezone в timestamp with time zone

      sysdate и dbtimezone разные в базе данных Oracle объясняют разницу между dbtimezone, system timezone и sessiontimezone.

      А вот как синхронизировать sessiontimezone с system timezone, если это необходимо:

      Похожие вопросы:

      какая польза от transparent. which места его использования для него.

      Я побежал select dbtimezone, sessiontimezone from dual который вернул -04:00 и -06:00 соответственно. Я тоже побежал select TZ_OFFSET('US/Eastern') EST_offset, TZ_OFFSET('America/Denver') Mtn Time.

      Какая польза от System.in.read() в java? Пожалуйста, объясните это.

      Есть ли в Oracle плавный способ получить числовую разницу между SESSIONTIMEZONE и DBTIMEZONE в текущий момент (когда я выполняю вызов)? Например: SELECT SESSIONTIMEZONE, DBTIMEZONE FROM DUAL;.

      Я хочу знать, что делает следующий код. Какая польза от request.referer ? @board = request.referer['dashboard'] if request.referer

      Мне трудно понять, какая здесь польза typedef - typedef char TYPE_SSOSettingError; typedef void (*ans_executeDomainRegistration) (TYPE_SSOSettingError); Из первой строки Я понимаю, что.

      Какая польза от Ретроламбды? Где мы используем фреймворк Retrolambda?

      У меня есть приложение django, работающее на ubuntu-14.04, а база данных-oracle. Часовые пояса следующие django - настройки - TIME_ZONE = 'UTC' ubuntu - Asia/Kolkata oracle dbtimezone - UTC oracle.


      В связи с тем, что накопилось несколько вопросов и решений по работе со временем, решил сделать небольшой обзор.


      Работа с различными типа данных в базах данных

      MYSQL

      В mysql существует несколько стандартных типов данных для представления времени, мы рассмотрим TIMESTAMP и DATETIME .
      В документации говорится, что к некоторым типам данных применяется политика конвертирования, а к некоторым — нет.
      На практике все намного интереснее. Рассмотрим несколько примеров:
      Создадим таблицу:

      Установим текущую зону для Москвы (в Москве с недавних пор нет перехода на летнее время, и время UTC+4):

      Создадим две записи с летним и зимним временем соответственно:

      Посмотрим, что показывает выборка этих дат из базы данных:

      Видим, что в обоих колонках значения одинаковые, это происходит потому что функция UNIX_TIMESTAMP рассматривает значение аргумента в текущей зоне и конвертирует его в UTC. Очевидно, что одинаковые значения одинаково сконвертируются в одно и то же значение Mon, 10 Dec 2012 11:08:05 UTC .
      Теперь переезжаем в Лондон!

      Тут нет ничего удивительного, согласно документации, TIMESTAMP , перед тем как вставиться в базу конвертируется в UTC, поэтому после того как мы сменили текущую зону база данных нам выдает значение этого времени в текущей зоне. Значения типа DATETIME не изменились.
      Теперь рассмотрим более детально работу алгоритма для Москвы. Значения для ts при вставке сконвертировались в UTC, и при выборке переводились в значения в соответствии с текущей зоной (как и для Лондона) 15 часов, а при выборе UNIX_TIMESTAMP — они просто отображались как они сохранены в базе.
      Теперь уже ожидаемый результат для Лондона:

      Значения ts не изменились, а значения dt рассматриваются как значения в текущий зоне, поэтому летнее время (первая запись) 1339337285 = Sun, 10 Jun 2012 14:08:05 GMT , а зимнее время (нижняя запись) 1355152085 = Mon, 10 Dec 2012 15:08:05 GMT .
      На всякий случай проверим поведение для UTC.

      • При работе с DATETIME и переезде сервера (неправильной настройке временной зоны во время вставки или импорта данных) с потерей информации о времени смены временной зоны сервера/соединения вы потеряете информации о действительном времени событий. Например, мы создали записи в 15 часов по московскому времени (импортировали данные в базу из backup’а), потом настроили наш сервер на UTC и не заметили, что до этого временная зона была московской. В результате вместо 11 часов по UTC оба наших заказа теперь сделаны на 4 часа позже — в 15 часов, а могли бы быть и в другой день. Поэтому на мой взгляд работать надо с TIMESTAMP .
      • Так же, чтобы не возникало лишних проблем при отладке на сервере лучше иметь зону UTC, и работать с данными в UTC, а на клиентской части отображайте в той зоне, в которой хочет клиент.
      • Так же хороший пример в конце статьиfeedbee.
      • Чтобы избежать проблем с leap second так же стоит работать с unix epochs в UTC (см. раздел про Leap second).
      SQLite3

      Рассмотрим ситуацию с sqlite3. Согласно документации в sqlite нет типа данных для сохранения времени, но есть функции для работы со временем, сохраненным в виде текста, числа с плавающей точкой и в виде целого числа. В целом эти представления принципиально ничем не отличается. Можно считать, что в sqlite текущая временная зона не используется, если вы не используете модификаторы localtime и utc. Например, вне зависимости от настроек системы, CURRENT_TIMESTAMP имеет значение в UTC.

      Поэтому конвертируйте свои данные в вашей программе в utc и используйте unix epochs, чтобы не искать ошибки при парсинге строк.
      Функции для отладки:

      Как пользователь видит время

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

      С-функции по работе со временем

      Во-первых, очень полезно ознакомиться с описанием работы со временем в glibc. Мы же рассмотрим несколько примеров, касающихся результатов работы нескольких функций в разных временных зонах. Оказывается, даже в документации говорится, что struct tm (далее broken-down time) обычно используется только для отображаения пользователям (из-за наглядности), т.е. в вашей программе лучше использовать другие более подходящие типы данных.
      Рассмотрим несколько примеров:

      Конвертирует simple time в broken-down time, выраженное относительно пользовательской зоны.

      зона в системе UTC Europe/Moscow Europe/London
      вывод hour 11 15 12
      вывод isdst 0 0 1
      вывод zone UTC MSK BST

      зона в системе UTC Europe/Moscow Europe/London
      вывод hour 11 15 11
      вывод isdst 0 0 0
      вывод zone UTC MSK GMT

      Возвращает значение для зоны UTC вне зависимости от зоны пользователя.

      зона в системе UTC Europe/Moscow Europe/London
      вывод hour 11 11 11
      вывод isdst 0 0 0
      вывод zone GMT GMT GMT

      зона в системе UTC Europe/Moscow Europe/London
      вывод hour 11 11 11
      вывод isdst 0 0 0
      вывод zone GMT GMT GMT

      (синоним timelocal, но редко встречается)
      Конвертирует broken-down time в simple time.
      Внимание: выставляет у аргумента текущую зону.
      Поле tm_zone не рассматривается как аргумент, считается, что время задано в текущей временной зоне и возвращается время в UTC.

      зона в системе UTC Europe/Moscow Europe/London
      вывод t 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) 1339312085 (Sun, 10 Jun 2012 07:08:05 GMT) 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT)
      вывод hour 11 11 12
      вывод isdst 0 0 1
      вывод gmtoff 0 14400 (4*60*60) 3600 (1*60*60)
      вывод zone UTC MSK BST

      Обратите внимение на то, что поля tm_hour и tm_isdst изменились для Лондона, это часть процесса нормализации полей структуры broken-down time.
      теперь для

      зона в системе UTC Europe/Moscow Europe/London
      вывод t 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) 1355123285 (Mon, 10 Dec 2012 07:08:05 GMT) 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT)
      вывод hour 11 11 11
      вывод isdst 0 0 0
      вывод gmtoff 0 14400 (4*60*60) 0
      вывод zone UTC MSK GMT

      Работает в UTC.

      зона в системе UTC Europe/Moscow Europe/London
      вывод t 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT) 1339326485 (Sun, 10 Jun 2012 11:08:05 GMT)
      вывод hour 11 11 11
      вывод isdst 0 0 0
      вывод gmtoff 0 0 0
      вывод zone GMT GMT GMT
      теперь для

      зона в системе UTC Europe/Moscow Europe/London
      вывод t 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT) 1355137685 (Mon, 10 Dec 2012 11:08:05 GMT)
      вывод hour 11 11 11
      вывод isdst 0 0 0
      вывод gmtoff 0 0 0
      вывод zone GMT GMT GMT

      Вывод:
      Если вы хотите отобразить время пользователю в вашей программе на пользовательском компьютере, то используйте функции timelocal/localtime , если вы работает на сервере, то используйте функции timegm/gmtime . Так же, устанавливайте на сервере зону UTC, на случай, если вдруг кто-то из ваших коллег или в сторонней библиотеке использует *local* функции. Даже на компьюетере пользователя храните и работайте со временем в UTC, так, если он сменит свою зону, все даты останутся правильными.

      Примечание

      Настройка временных зон в linux

      • Способ первый (работает на deb-based дистрибутивах):
        Выполнить в терминале команду и следовать инструкциям (“UTC” находится в разделе “Etc”):
        sudo dpkg-reconfigure tzdata
      • Способ второй (работает, наверное везде):
        Выполнить в терминале команду:

      Читайте также: