目前的安排是： SAP DSO：包含dd-mm-yyyy形式的数据列。
BODS 作业从 DSO 获取数据并加载到登陆表。 Teradata 中对应的日期列是 dd-mm-yy。
将日期加载到 teradata 时，2014 年将转换为 1914 年。 不涉及转换。源和目标之间的直接映射。
这个问题在几个月前才开始发生。不知道要检查什么。
【问题讨论】：
标签： sap etl teradata sap-data-services
要在日期中显示正确的年份，请使用 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 中遇到了类似的问题。
在使用日期时间格式为dd/mm/yyyy 创建了多个日期字段的表，并使用这种格式构建了一个 Universe 之后，我在测试时注意到某些日期结果显示不正确，例如01/07/1993 显示为 01/07/2093。这是由于加载到表中的数据只有 2 个 yy 数字，例如01/07/93其中 Oracle 期望使用 4 个 yyyy 数字的 DateTime 格式。
反过来，Oracle 将年份格式强制为 4 位数字，但由于年份是上个世纪（20 世纪）但存储在 21 世纪，因此年份的前缀是错误的。
为了解决这个问题，我使用了rrrr DateTime 格式作为年份。 Oracle 在link 上提供了完整的解释，进一步的解释可以在here 找到。
当我重新创建日期时间格式为dd-mm-rrrr 的表格时，日期显示正确。
我希望这会有所帮助。
【讨论】：
CenturyBreak 的 DBSControl 指定哪些两位数年份被解释为 20 世纪，哪些被解释为 21 世纪。如果您的系统将此配置为非零值，这是默认值，那么这很可能是您看到数据行为的原因。
CenturyBreak 不影响以数字形式输入的四位数年份或日期。
如果 CenturyBreak=10，则“00/01/01”和“09/01/01”等字符串被解释为 2000 和 2009。插入为“14/01/01”的字符串被解释为 1914。
与您的 DBA 核实以确定 CenturyBreak 是否已设置为非零值或将您的数据输入显式转换为数字日期值。
【讨论】：