Início / dba / Perguntas / 159450
Accepted
Jason Krs
Asked: 2016-12-30 06:21:30 +0800 CST

Você pode ajudar a esclarecer a confusão do ORACLE Timestamp com o fuso horário local?

  • 772

Abaixo está uma descrição do ORACLETIMESTAMP WITH LOCAL TIME ZONE

... os dados armazenados no banco de dados são normalizados para o fuso horário do banco de dados e o deslocamento do fuso horário não é armazenado como parte dos dados da coluna. Quando os usuários recuperam os dados, o Oracle os retorna no fuso horário da sessão local dos usuários .

O que os dados armazenados no banco de dados são normalizados para o fuso horário do banco de dados ? Normalizado... como?

Se for normalizado, por que não é retornado de acordo com o fuso horário do servidor em vez do fuso horário da sessão local dos usuários ... Como é "sessão" e não "servidor"?

oracle

2 respostas

  1. Best Answer

    Normalizado significa que as informações de fuso horário não são armazenadas. Ao armazenar esses dados, o valor do carimbo de data/hora é ajustado automaticamente para estar no mesmo fuso horário do servidor de banco de dados. Ao recuperar esses dados, o valor do carimbo de data/hora é ajustado automaticamente para estar no mesmo fuso horário do cliente.

    Por exemplo, simulo que meu cliente está em um fuso horário diferente:

    $ export TZ=America/Los_Angeles
$ sqlplus user/password@orcl

    Crie uma tabela para armazenar valores de carimbo de data/hora:

    SQL> create table t1 (t timestamp with local time zone);

Table created.

    Agora observe como meu horário local (cliente) é diferente ( current_timestamp) do horário do servidor ( systimestamp):

    SQL> select current_timestamp, systimestamp from dual;

CURRENT_TIMESTAMP                   SYSTIMESTAMP
----------------------------------- -----------------------------------
29-DEC-16 06.36.09.364628 AM -08:00 29-DEC-16 03.36.09.364623 PM +01:00

    Agora eu insiro minha hora local:

    SQL> insert into t1 (t) values (current_timestamp);

1 row created.

SQL> commit;

Commit complete.

SQL> select t from t1;

T
---------------------------------------------------------------------------
29-DEC-16 06.36.32.100571 AM

    Apenas o que eu esperava. Mas se eu examinar o conteúdo real:

    SQL> select dump(t) from t1;

DUMP(T)
----------------------------------------------------
Typ=231 Len=11: 120,116,12,29,16,37,33,5,254,151,120

    TIMESTAMPé armazenado como:

    • 1º byte: Os dois primeiros dígitos do ano: 20 + 100 = 120
    • 2º byte: Últimos dois dígitos do ano: 16 + 100 = 116
    • 3º byte: Mês: 12
    • 4º byte: Dia: 29
    • 5º byte: Hora: 15 + 1 = 16
    • 6º byte: Minuto: 36 + 1 = 37
    • 7º byte: Segundo: 32 + 1 = 33
    • 8º-11º bytes: frações de segundo

    As informações de fuso horário estariam no 12º e 13º byte, mas não são armazenadas com esse tipo de dados.

    Portanto, os dados reais armazenados são 2016-12-29 15:36:32:..., porque meu banco de dados está no CETfuso horário.

    Se eu fingir estar em outro fuso horário diferente, minha consulta retornará um carimbo de data/hora ajustado para esse fuso horário:

    $ export TZ=Asia/Hong_Kong
$ sqlplus user/password@orcl


SQL> select t from t1;

T
---------------------------------------------------------------------------
29-DEC-16 10.36.32.100571 PM
    • 7

  2. Muitas vezes, quando você precisa trabalhar com dados de fuso horário, uma abordagem comum é:

    Armazene todos os horários internamente no horário UTC e exiba-os no nível do aplicativo de acordo com as configurações do usuário local.

    Isso é exatamente o que TIMESTAMP WITH LOCAL TIME ZONEestá fazendo, mas no nível SQL. A única diferença é:

    Armazene todos os horários internamente no horário DBTIMEZONE e exiba-os no nível do aplicativo (ou seja, no SQL) de acordo com as configurações do usuário local (ou seja, SESSIONTIMEZONE).

    Uma vez que você criou uma tabela com uma TIMESTAMP WITH LOCAL TIME ZONEcoluna e esta tabela contém quaisquer dados que você não pode DBTIMEZONEmais alterar - o que parece lógico quando você considera as declarações acima.

    • 1

relate perguntas