甲骨文是不是面临千年虫问题？ [关闭]

Posted 2023-03-31

【中文标题】甲骨文是不是面临千年虫问题？ [关闭]

【英文标题】：Did Oracle face the Y2K problem? [closed]甲骨文是否面临千年虫问题？ [关闭]

【发布时间】：2010-08-12 14:10:39

【问题描述】：

我的猜测是它不应该有，因为他们在日期中也使用世纪

来自here，

DATE 数据类型存储年（包括世纪）、月、日、小时、分钟和秒（午夜之后）。

它面对the problem吗？

【问题讨论】：

投票结束的人也是如此：我认为这既是一个编程问题，也是一个活生生的问题。仅仅因为千年虫是十年前的事，并不意味着潜在的不良做法仍然没有被普遍使用。

但它支持闰秒吗？

【参考方案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 错误是一个应用程序问题，而不是存储问题。现有的每个应用程序仍将允许用户编写日期，因为 09 年 14 月 14 日使该错误永久存在。就 RR 面具鼓励这种懒惰而言，它使事情变得更糟。

【参考方案2】：

正如 APC 所说，自 V7 以来，Oracle 以完整的日期时间格式存储日期，并且大多数客户端应用程序还在 2K 截止日期之前的某个时间更正了任何使用显式 -YY 格式掩码的情况。

但是，我已经看到自 2K 以来发生的错误，人们重新使用 -YY 格式掩码，并且在测试中没有注意到，因为他们的所有测试数据都是 Y2K 后的 - 特别是在进行日期/字符串/日期操作时- 一个人为的例子：

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

如果您正在处理将日期和时间存储为单独的数据库列的遗留系统，这种逻辑是很常见的。语法可能是特定于 Oracle 的，但问题实际上是通用编程问题。

我发现与 Oracle 更相关的问题是 NLS 日期设置。我见过 DBA 重建数据库但将默认格式设置回 -YY，我还看到 JDBC 连接将会话格式设置为 -YY、从操作系统环境继承并覆盖数据库导致的错误默认。

这些都不是 Oracle 软件的故障，只要系统和编程语言允许 2 位数年份，“Y2K”问题就会存在。

【讨论】：

+1。只要程序员懒得使用适当的抽象，问题就会出现。虽然 Y2K 已基本解决，但时区问题仍然比比皆是，因为程序员不了解“UTC 时间戳”和“时区 X 中的日历日期时间”之间的区别。

【参考方案3】：

是的，看起来他们确实做到了：

http://news.cnet.com/Oracle-offers-free-Y2K-upgrade/2100-1001_3-222123.html

但不确定他们是否遇到了您所指的那个人。

【参考方案4】：

可能有点跑题了，但是....

在 Y2K 期间，我一直在为 Oracle 支持工作，包括转存之夜本身。

我们整晚都接到一个电话 - 一位客户要求提供一份 Oracle 千年虫声明的副本。有点晚了我想。 :)

除此之外，不要记得收到任何关于千年虫问题的电话。 （请注意，我没有在 RDBMS 服务器组工作）