为什么 datetime 可以允许这种十进制格式，但 datetime2 不允许？答案

【问题标题】：Why can datetime allow this decimal format but datetime2 won't?为什么 datetime 可以允许这种十进制格式，但 datetime2 不允许？
【发布时间】：2021-04-19 21:31:15
【问题描述】：

我刚刚遇到了一个问题，我的程序无法将 string 转换为 datetime2 值。值为12/17.2020。将其转换为datetime 时，它可以工作，但将其转换为datetime2 时却没有。这是什么原因？ 12/17.2020怎么可能有效？

【问题讨论】：

SQL Server 支持许多旧的“不规则”功能以保持向后兼容性。 Datetime2 是一种新的数据类型，MS 决定不支持这个（以及其他东西，比如使用数学 + 运算符）。

标签： sql sql-server datetime type-conversion datetime2

【解决方案1】：

12/17.2020 一开始就是一种糟糕的格式，不仅因为标点符号混合，还因为it is ambiguous。幸运的是，我们知道那是 mm/dd.yyyy，但如果你给我们看 12/08.2020 会怎样？

12/17.2020 怎么算有效？

仅仅因为它在一种情况下有效并不意味着您应该使用它（或者对“破坏”它的新类型感到愤怒）。出于任何正当理由，它都是无效的 - 这种格式肯定没有在 Supported Literal String Formats section of the datetime docs 中列出。

之所以有效，是因为旧的数据类型 (datetime/smalldatetime) 更宽容。他们还允许您像这样使用速记：

DECLARE @d datetime;
SET @d = 0;
SELECT @d + 1;

试试date或datetime2，你会遇到：

消息 206，级别 16，状态 2
操作数类型冲突：int 与 datetime2 不兼容

为什么并不重要。您需要的是一种解决方法。

理想情况下，您可以将入站格式修复为所有日期/时间数据类型普遍理解的明确格式，并且不受区域设置、语言设置和日期格式设置等问题因素的影响：
```
yyyymmdd
```
在某些情况下您可以使用horribly inefficient FORMAT function 或先替换来解决此问题，但是，如果您无法更改传入格式，您最简单的答案可能是只运行两次转换：
```
SELECT CONVERT(datetime2, CONVERT(datetime, '12/17.2020'));
```
如果您只是试图盲目地将12/17.2020 传递到存储过程参数中，或者将其直接插入应用程序的列中，那么您将不走运。请参阅 1。

【讨论】：