SQL Server中Convert('yymmdd'转datetime)失效：同转换逻辑在不同服务器表现不一致

这个问题我之前帮同事排查过，核心就是SQL Server的日期解析逻辑依赖环境设置，没指定转换样式时很容易踩跨服务器的坑！

当你执行CONVERT(datetime,'210319')却不指定第三个style参数时，SQL Server会根据当前会话的DATEFORMAT设置或者服务器默认语言来解析这个6位字符串：

• 其中一台服务器的日期格式可能是ymd（年/月/日），它会把'210319'正确解析为2021年3月19日；
• 另一台服务器如果是mdy（月/日/年）规则，就会把前两位'21'当成月份——这显然超出了1-12的合法范围，直接触发"varchar转datetime超出范围"的错误。

另外你提到的Convert('yymmdd' AS datetime)写法本身就有语法逻辑问题：CONVERT的正确语法是CONVERT(目标数据类型, 要转换的表达式[, 样式])，你把字符串'yymmdd'当成了要转换的表达式，这个字符串本身根本不是合法日期格式，自然无法完成转换。

按可靠性从高到低，推荐这几种解决方式：

1. 强制指定转换样式（最推荐） #

在CONVERT函数里明确对应yymmdd格式的样式参数（值为12），这样不管服务器的日期格式设置如何，都能精准解析：

-- 正确解析'210319'为2021-03-19
CONVERT(datetime, '210319', 12)

如果你的日期字符串是yyyymmdd格式（比如'20210319'），更推荐用样式112（国际标准无歧义格式）：

CONVERT(datetime, '20210319', 112)

2. 统一会话/服务器的日期格式 #

如果不想修改存储过程代码，可以在执行存储前先设置当前会话的日期格式：

-- 设置会话日期格式为年-月-日
SET DATEFORMAT ymd;
-- 再执行你的存储过程
EXEC 你的存储过程名;

不过这种方式不够可靠，因为其他操作可能会修改会话的DATEFORMAT，或者不同客户端的默认会话设置不同，容易再次出现不一致问题。

3. 使用无歧义的日期字符串格式 #

尽量避免使用依赖环境的日期格式，改用SQL Server能全局识别的无歧义格式，比如：

• yyyy-mm-dd（如'2021-03-19'）
• yyyymmdd（如'20210319'）
  这些格式不需要指定样式参数，在任何SQL Server环境下都能被正确解析。

内容的提问来源于stack exchange，提问作者pushparani