Databricks中Y2K日期值格式化问题咨询

你好呀，我来帮你理清这个日期解析的问题～

你遇到的情况是典型的Y2K两位年份解析问题：Spark SQL（Databricks基于Spark）默认处理两位年份yy格式时，会把00-69的年份值解析为2000-2069年，70-99则解析为1970-1999年，所以01-Jan-01里的01就被自动归到2001年了，这就是为什么结果不符合预期。

针对这个问题，给你两个实用的解决办法：

方法一：自定义逻辑调整年份（推荐，更灵活可控） #

通过CASE WHEN判断解析后的日期，如果年份超出你的业务预期范围（比如大于2050年），就减去100年修正：

SELECT 
  '01-Jan-01' AS badDate,
  -- 先解析日期，再判断是否需要减100年
  CASE 
    WHEN to_date('01-Jan-01', 'dd-MMM-yy') > date_add(current_date(), 365*50) -- 假设业务中不会有超过50年后的日期
    THEN add_months(to_date('01-Jan-01', 'dd-MMM-yy'), -1200) -- 1200个月=100年，比直接减天数更准确（兼容闰年）
    ELSE to_date('01-Jan-01', 'dd-MMM-yy')
  END AS corrected_date

如果你的业务明确所有两位年份都是19xx年，也可以直接写死修正：

SELECT 
  '01-Jan-01' AS badDate,
  add_months(to_date('01-Jan-01', 'dd-MMM-yy'), -1200) AS corrected_date

方法二：修改Spark会话的日期解析规则 #

如果希望全局统一调整两位年份的解析逻辑，可以设置Spark的会话参数，指定默认的世纪起始年份。比如在Databricks notebook中先运行：

-- 设置两位年份默认解析为1900-1999年
SET spark.sql.datetime.parser.defaultCenturyStart=1900;

之后再运行你的原查询，to_date('01-Jan-01','dd-MMM-yy')就会返回1901-01-01了。不过这个设置会影响整个会话的日期解析，需要根据实际业务场景评估是否适用。

另外补充一下你原查询里的小细节：date_format函数的第一个参数如果是字符串，会先自动转成日期再格式化，所以它的行为和to_date是一致的，也会受同样的解析规则影响。

备注：内容来源于stack exchange，提问作者Jamie