0

目前的安排是： SAP DSO：包含 dd-mm-yyyy 形式的数据列。

BODS 作业从 DSO 获取数据并加载到登陆表。Teradata 中对应的日期列是 dd-mm-yy。

将日期加载到 teradata 时，2014 年将转换为 1914。不涉及任何转换。源和目标之间的直接映射。

这个问题在几个月前才开始发生。不确定要检查什么。

4

2 回答 2

1

要在日期中显示正确的年份，请使用 DateTime 格式dd-mm-rrrr。

当日期存储在一个世纪但引用另一个世纪时，日期可能会以错误的前缀显示。rrrr年份格式是这样工作的；

如果指定的两位数年份是 00 到 49，则

  • 如果当前年份的后两位数字是 00 到 49，则返回的年份与当前年份的前两位数字相同。

  • 如果当前年份的后两位是 50 到 99，则返回年份的前 2 位比当前年份的前 2 位大 1。

如果指定的两位数年份是 50 到 99，则

  • 如果当前年份的后两位为 00 到 49，则返回年份的前 2 位比当前年份的前 2 位小 1。

  • 如果当前年份的后两位数字是 50 到 99，则返回的年份与当前年份的前两位数字相同。

我在 BOXI 3.1 和 Oracle 中遇到了类似的问题。

在创建了许多具有 DateTime 格式的日期字段的表dd/mm/yyyy并构建了一个具有这种格式的 Universe 之后，我注意到在测试中某些日期结果显示不正确，例如01/07/1993显示为01/07/2093。这是由于加载到表中的数据只有 2yy位数字，例如01/07/93Oracle 期望使用 4 位数字的 DateTime 格式yyyy。

反过来，Oracle 将年份格式强制为 4 位数字，但由于年份是上个世纪（20 世纪）但存储在 21 世纪，因此错误的世纪前缀在年份上。

为了解决这个问题，我使用了rrrr当年的 DateTime 格式。Oracle 在此链接上的完整解释，进一步的解释可以在这里找到。

当我使用 DateTime 格式重新创建表格时dd-mm-rrrr，日期显示正确。

我希望这有帮助。

于 2015-05-01T10:49:03.147 回答
0

CenturyBreak 的 DBSControl 指定哪些两位数年份被解释为 20 世纪，哪些被解释为 21 世纪。如果您的系统将此配置为非零值，这是默认值，那么这很可能是您看到数据行为的原因。

CenturyBreak 不影响以数字形式输入的四位数年份或日期。

如果 CenturyBreak=10，则诸如“00/01/01”和“09/01/01”之类的字符串被解释为 2000 和 2009。插入为“14/01/01”的字符串被解释为 1914。

请咨询您的 DBA 以确定 CenturyBreak 是否已设置为非零值或将您的数据输入显式转换为数字日期值。

于 2014-11-24T17:00:11.260 回答