Oracle是否面临Y2K问题？

Question

我的猜测是它没有,因为它们在约会中也使用了几个世纪

从这里开始,

DATE数据类型存储年份(包括世纪),月份,日期,小时,分钟和秒(午夜之后).

它遇到了问题吗？

Answer 1

是的,Oracle受到Y2K错误的影响.在Oracle 7之前,数据库没有存储世纪.向后兼容性意味着Oracle 7数据库使用DD-MON-YY作为日期的默认格式掩码.如果您使用该掩码创建日期,则世纪默认为当前世纪.这仍然存在上个世纪的日期或下个世纪的日期问题.严格来说,这是一个应用程序问题而不是存储问题.

作为此解决方案,Oracle将RR元素引入了日期掩码,该日期掩码在日期窗口的基础上衍生出一个世纪.这是出于显示目的.当然,这种解决方法现在已经成为一种嵌入式功能,并且会导致各种各样的问题.尤其是因为应用程序将其用作输入格式掩码,而不是要求用户明确输入一个世纪.

无论如何,这是它的工作原理.

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>

表格内容:

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>

1 - 49年分配19和0,50-99分配20.

需要重申的是,在Oracle中,Y2K错误是一个应用程序问题,而不是存储问题.现有的每个应用程序仍然允许用户编写日期,因为14-OCT-09正在使错误永久化.如果RR面具鼓励这种懒惰,那就会使事情变得更糟.