Pergunta

Meu palpite é que não deveria, porque eles usam séculos também em datas

De aqui,

O tipo de dados DATE armazena o ano (incluindo o século), o mês, o dia, as horas, os minutos e os segundos (depois da meia-noite).

Será que cara o problema?

Foi útil?

Solução

Sim, o Oracle foi afetado pelo bug y2k. Antes do Oracle 7, o banco de dados não armazenou o século. A compatibilidade com versões anteriores significava que o banco de dados Oracle 7 usava DD-Mon-YY como a máscara de formato padrão para datas. E se você criar uma data usando essa máscara, o século padrão no século atual. O que ainda deixa problemas com datas do século anterior agora ou datas no próximo século. Estritamente falando, este é um problema de aplicativo e não um problema de armazenamento.

Como um trabalho para este Oracle introduziu o elemento RR na máscara de data, que deriva um século com base em uma janela de data. Isso foi destinado a fins de exibição. Obviamente, essa solução alternativa se tornou um recurso incorporado agora e leva a todos os tipos de problemas próprios. Não menos importante, porque os aplicativos o usaram como uma máscara de formato de entrada, em vez de exigir que os usuários entrem explicitamente um século.

Enfim, eis como funciona.

SQL> insert into t72 values (1, to_date('12-MAY-32', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (2, to_date('12-MAY-99', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (3, to_date('12-MAY-50', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (11, to_date('12-MAY-32', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (12, to_date('12-MAY-99', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (13, to_date('12-MAY-50', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (14, to_date('12-MAY-49', 'DD-MON-RR'))
  2  /

1 row created.

SQL>

O conteúdo da tabela:

SQL> alter session set nls_date_format = 'DD-MON-YYYY'
  2  /

Session altered.

SQL> select * from t72
  2  /

        ID D
---------- -----------
         1 12-MAY-2032
         2 12-MAY-2099
         3 12-MAY-2050
        11 12-MAY-2032
        12 12-MAY-1999
        13 12-MAY-1950
        14 12-MAY-2049

7 rows selected.

SQL>

Os anos 1-49 são atribuídos 19 e 0, 50-99 recebem 20.


Vai repetir que, no Oracle, o Y2K Bug é um problema de aplicativo, não um armazenamento. Cada aplicativo existente ainda permite que os usuários escrevam datas, pois 14-OCT-09 está perpetuando o bug. Na medida em que a máscara RR incentive essa preguiça, piorou as coisas.

Outras dicas

Como disse a APC, a Oracle armazena datas em um formato completo de data e hora desde a V7, e a maioria dos aplicativos clientes também corrigiu qualquer uso de máscaras explícitas no formato -YY algum tempo antes do prazo de 2K.

No entanto, tenho visto bugs ocorrendo desde 2K, onde as pessoas voltaram a usar máscaras de formato -YY e não perceberam nos testes porque todos os seus dados de teste são pós-Y2K - especialmente ao fazer manipulações de data/string/data - um artificial exemplo :

TO_DATE(TO_CHAR(a_date_column,'DD-MM-YY')||'12:00','DD-MM-YYHH24:MI')

Esse tipo de lógica é bastante comum se você estiver lidando com um sistema legado que armazena data e hora como colunas separadas do banco de dados.A sintaxe pode ser específica do Oracle, mas o problema é realmente de programação geral.

Onde tenho visto problemas mais relacionados ao Oracle foi em torno das configurações de data do NLS.Já vi um DBA reconstruir um banco de dados, mas definindo o formato padrão de volta para -YY, e também vi erros causados ​​quando uma conexão JDBC estava definindo o formato da sessão para -YY, herdado do ambiente do sistema operacional e substituindo o banco de dados padrão.

Nenhum destes são defeitos do software da Oracle, apenas vale a pena estar ciente de que os problemas do 'Y2K' existirão enquanto os sistemas e as linguagens de programação permitirem anos de 2 dígitos.

Sim, parece que eles fizeram:

http://news.cnet.com/oracle-fhers-free-y2kup upgrade/2100-1001_3-222123.html

Não tenho certeza se eles enfrentaram o exato ao qual você está se referindo.

Possivelmente um pouco fora do tópico, mas ....

Eu estava trabalhando para o apoio do Oracle durante o período Y2K, incluindo a própria noite.

Recebemos uma ligação a noite toda - um cliente pedindo uma cópia da declaração Y2K da Oracle. Um pouco tarde de methinks. :)

Fora isso, não lembre -se de receber pedidos de problemas Y2K. (Observe que eu não trabalhei no grupo de servidores RDBMS)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top