Sap 2014年在董事会工作中转换为1914年

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

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

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

---

这个问题几个月前才开始出现。不确定要检查什么。

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

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

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

---

请与DBA联系，确定CenturyBreak是否已设置为非零值，或将数据输入显式转换为数字日期值。

要在日期中显示正确的年份，请使用日期时间格式

dd mm rrrrr

当日期存储在一个世纪中，但引用另一个世纪时，日期可能会显示错误的前缀。

rrrr

year格式也是如此

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

• 如果当前年份的最后两位数为00到49，则 返回的年份具有与当前年份相同的前两位数字

• 如果当前年份的最后两位数为50到99，则 返回年份的前2位数字比前2位数字大1 本年度的数字

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

• 如果当前年份的最后两位数为00到49，则 返回年份的前2位数字比前2位数字小1 本年度的

• 如果当前年份的最后两位数为50到99，则 返回的年份具有与当前年份相同的前两位数字

我在Boxi3.1和Oracle中遇到了类似的问题

在创建了许多带有日期字段的表，其日期时间格式为

dd/mm/yyyyy

，并使用这种格式构建了一个世界之后，我在测试中注意到一些日期结果显示不正确，例如

01/07/1993

显示为

01/07/2093

。这是因为加载到表中的数据只有2位

yy

数字，例如

01/07/93

，而Oracle希望使用4位

yyy

的日期时间格式

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

为了解决这个问题，我使用了

rrrrr

DateTime格式。甲骨文对此有充分的解释，可以找到进一步的解释

当我重新创建日期时间格式为

dd mm rrrrr

的表时，日期显示正确

我希望这有帮助