Est-ce le problème Oracle face à Y2K? [fermé]

Question

Je suppose que ce shouln't ont parce qu'ils utilisent des siècles aussi dans les dates

De ,

  

Le type de données DATE stocke l'année (y compris le siècle) , le mois, le jour, les heures, les minutes et les secondes (après minuit).

Est-ce que le face le problème ?

Answer 1

Oui, Oracle a été affecté par le bug Y2K. Avant Oracle 7 la base de données n'a pas stocké du siècle. rétrocompatibilité signifie que la base de données Oracle 7 utilisé DD-MON-YY comme masque de format par défaut pour les dates. Et si vous créez une date en utilisant ce masque les paramètres par défaut du siècle au cours de ce siècle. Ce qui laisse encore des problèmes avec date du siècle précédent ou maintenant les dates du prochain siècle puis. Au sens strict cela est une question d'application plutôt que d'un problème de stockage.

En tant que travail autour de cette Oracle a introduit l'élément RR au masque de date, qui dérive d'un siècle sur la base d'une fenêtre de date. Il était destiné à des fins d'affichage. Bien sûr, cette solution de contournement est devenu une fonction intégrée maintenant et conduit à toutes sortes de problèmes qui lui sont propres. Pas moins parce que les applications utilisées comme un masque de format d'entrée au lieu de demander aux utilisateurs d'entrer explicitement un siècle.

Quoi qu'il en soit, voici comment cela fonctionne.

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>

Le contenu de la table:

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>

Années 1-49 sont affectés 19 et 0, 50 à 99 sont donnés 20.

---

Il faut répéter que dans Oracle le bogue de Y2K est un problème d'application non un moment de stockage. Chaque application existe encore permet aux utilisateurs sera de dates d'écriture comme 14-Oct-09 est perpétuant le bogue. Dans la mesure où le masque RR encourage cette paresse, il a fait qu'empirer les choses.

Answer 2

Comme dit APC, Oracle a enregistré les dates dans un format de date à temps plein depuis V7, et la plupart des applications clientes également corrigées toute utilisation de masques de format explicites -YY un certain temps avant la date limite 2K.

Cependant, j'ai vu des insectes qui se produisent depuis 2K où les gens ont glissé de nouveau dans la réutilisation des masques de format -YY, et ne pas avoir remarqué à tester, car toutes leurs données de test post-Y2K - en particulier lorsque vous faites date / chaîne / manipulations de date - un exemple artificiel:

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

Ce genre de logique est assez courant si vous avez affaire à un ancien système qui stocke date et l'heure sous forme de colonnes de base de données séparées. La syntaxe peut être Oracle spécifique, mais le problème est vraiment une programmation générale.

Là où j'ai vu des problèmes qui se rapportent plus à Oracle a été autour paramètres de date NLS. Je l'ai vu un DBA reconstruire une base de données, mais la définition du format par défaut au -YY, et je l'ai vu aussi des erreurs causées où une connexion JDBC a été la définition du format de session -YY, héritée de l'environnement du système d'exploitation, et la base de données remplaçant par défaut.

Aucune de ces défauts sont avec le logiciel d'Oracle, il paie juste pour se rendre compte que les problèmes Y2K »seront aussi longtemps que les systèmes et les langages de programmation permettent années à 2 chiffres.

Answer 3

Oui, on dirait qu'ils ont fait:

http: //news.cnet .com / Oracle-offre-sans Y2K la mise à niveau / 2100-1001_3-222123.html

Je ne sais pas s'ils ont fait face l'exact dont vous parlez bien.

Answer 4

Peut-être un peu hors-sujet, mais ....

Je travaillais pour le support d'Oracle au cours de la période de Y2K, y compris la nuit de déploiement sur lui-même.

Nous avons eu un appel toute la nuit - un client demandant une copie de la déclaration Y2K d'Oracle. Peu en retard. Methinks :)

Autre que cela, ne me souviens pas de recevoir des appels sur les problèmes Y2K. (Notez que je ne travaillais pas dans le groupe SGBDR serveur bien)