Oracle se enfrentó el problema Y2K? [cerrado]

Question

Mi conjetura es que shouln't tiene porque utilizan siglos también en fechas

aquí ,

  

El tipo de datos FECHA tiendas el año (incluyendo el siglo) , el mes, el día, las horas, los minutos y los segundos (después de medianoche).

Lo hizo frente a el problema ?

Answer 1

Sí, Oracle se vio afectada por el virus Y2K. Antes de Oracle 7 de la base de datos no almacenar el siglo. Compatibilidad hacia atrás significaba que la base de datos de Oracle 7 utiliza DD-MON-YY como la máscara de formato por defecto para las fechas. Y si crea una fecha con esa máscara los valores por defecto del siglo hasta el siglo actual. Lo cual deja todavía problemas con fechas desde el siglo anterior ahora o fechas en el próximo siglo después. Estrictamente hablando, esto es un problema de aplicación en lugar de un problema de almacenamiento.

Como en todo trabajo para este Oracle introdujo el elemento de RR a la máscara de la fecha, que se deriva de un siglo sobre la base de una ventana de fecha. Esto fue pensada para fines de visualización. Por supuesto, esta solución ha convertido en una característica incrustada ahora, y da lugar a todo tipo de problemas propios. Entre otras cosas porque las aplicaciones que utilizan como una máscara de formato de entrada en lugar de exigir a los usuarios introducir explícitamente un siglo.

De todos modos, aquí es cómo 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>

Los contenidos de la tabla:

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>

Años 1-49 se asignan 19 y 0, 50-99 se dan 20.

---

Vale la pena repetir que en Oracle el Y2K no es un problema de aplicación de un uno almacenamiento. Cada aplicación en existencia se sigue permitiendo a los usuarios a las fechas de escritura como 14-OCT-09 está perpetuando el error. En la medida en que la máscara RR alienta esta pereza que ha empeorado las cosas.

Answer 2

Como dijo APC, Oracle ha almacenado fechas en un formato completo de fecha y hora desde V7, y la mayoría de las aplicaciones cliente también corregido cualquier uso de máscaras de formato -YY explícitas algún tiempo antes de la fecha límite de 2K.

Sin embargo, he visto los errores que se producen desde 2K donde la gente ha vuelto a caer en la reutilización de máscaras de formato -YY, y sin darse cuenta en la prueba, porque todos sus datos de prueba es post-Y2K - sobre todo cuando se hace fecha / cadena de manipulaciones / fecha - un ejemplo artificial:

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

Este tipo de lógica es bastante común si se trata de un sistema heredado que almacena la fecha y la hora en forma de columnas de bases de datos separadas. La sintaxis puede ser Oracle específica, pero el problema es realmente una programación general.

¿Dónde he visto los problemas que se relacionan más con Oracle, ha sido por ajustes de fecha NLS. He visto un DBA reconstruir una base de datos, pero el establecimiento de la parte posterior formato predeterminado para -YY, y también he visto los errores causados ??en una conexión JDBC se ponía el formato de la sesión a -YY, heredado del entorno de sistema operativo, y anulando la base de datos por defecto.

Ninguno de estos son fallos con el software de Oracle, que sólo vale la pena ser conscientes de que los problemas 'Y2K' van a estar todo el tiempo que los sistemas y lenguajes de programación permiten años de 2 dígitos.

Answer 3

Si se ve como lo hicieron:

http: //news.cnet .com / Oracle-ofertas-sin-Y2K actualizar / 2100-1001_3-222123.html

No está seguro de si se enfrentan el exacto que se está refiriendo a pesar.

Answer 4

Posiblemente un poco fuera de tema, pero ....

yo estaba trabajando para el soporte de Oracle durante el período Y2K, incluyendo la noche misma de vuelco.

Tenemos una llamada toda la noche - un cliente pidiendo una copia de la declaración de Y2K de Oracle. Me parece bits finales. :)

Aparte de eso, no recuerda haber recibido ninguna llamada sobre los problemas del Y2K. (Tenga en cuenta que yo no trabajo en el grupo Servidor RDBMS sin embargo)