目前的安排是：SAP DSO：包含的数据列形式为dd-mm-yyy。
BODS作业从DSO中获取数据并加载到登陆表中，Teradata中对应的日期列为dd-mm-yy。
当日期加载到teradata时，2014年被转换为1914年，不涉及转换。源和目标之间直接映射。
这个问题几个月前才开始发生。不知道要检查什么。
要在日期中显示正确的年份，请使用DateTime格式。dd-mm-rrrr.
当日期存储在一个世纪，但指的是另一个世纪，日期可能会以错误的前缀显示。在 rrrr 年的格式是这样的。
如果指定的两位数年份是00至49，那么
如果当年的最后两位数字是00到49，那么返回的年份的前两位数字与当年相同，如果当年的最后两位数字是50到99，那么返回的年份的前两位数字比当年的前两位数字大1。
如果当年的最后两位数字是50到99，那么返回年份的前两位数字比当年的前两位数字大1。
如果指定的两位数年份是50～99，则
如果当年的最后两位数字是00到49，那么返回年份的前两位数字比当年的前两位数字少1。
如果当年的最后两位数字是50到99，那么返回的年份的前两位数字与当年相同。
我在BOXI 3.1和Oracle中也遇到了类似的问题。
在创建了一些带有DateTime格式的Date字段的表后，发现其格式为 dd/mm/yyyy我注意到，在测试中，一些日期结果显示不正确，如 01/07/1993 显示为 01/07/2093. 这是因为数据被加载到表中只有2个。yy 数字，例如 01/07/93而甲骨文则希望DateTime的格式为4 yyyy 数字。
反过来，甲骨文将年份的格式强制为4位数，但由于年份是在上个世纪（20），但存储在21世纪，所以错误的世纪被预置到了年份上。
为了解决这个问题，我使用了 rrrr 年的DateTime格式。甲骨文的完整解释在此 联系，进一步的解释可参见 此处.
当我用DateTime的格式重新创建表格时，我发现该表的格式为 dd-mm-rrrr，日期显示正确。
希望能帮到你。
CenturyBreak的DBS控件指定了哪些两位数的年份被解释为20世纪，哪些被解释为21世纪。如果您的系统将其配置为非零值，这是默认值，那么这很可能是您看到数据行为的原因。
CenturyBreak不影响四位数的年份或数字输入的日期。
如果CenturyBreak=10，像'00010101'和'090101'这样的字符串会被解释为2000和2009。插入为'140101'的字符串会被解释为1914年。
请与您的DBA检查以确定CenturyBreak是否已被设置为非零值，或者明确地将您的数据输入转换为数字日期值。