sql-server - 日期转换和文化 : Difference between DATE and DATETIME

Question

我写了很多关于字符串的 date 或 datetime 转换的答案。生活在德语国家，我习惯于处理非us_english日期格式，并且习惯使用安全文字(我更喜欢ODBC格式)和我从不使用没有第三个参数的CONVERT。这不是问题，请不要提供这个方向的答案...

人们经常会读到，格式yyyy-mm-dd是标准的(ISO8601、ANSI，等等)，因此与文化无关。

今天我必须编辑one of these older answers正如我在那里所说的，观察到的行为取决于其他因素。

问题是:

为什么(如果有原因)DATE 和 DATETIME 之间存在差异？

...至少在我的环境中，目前是 SQL Server 2014 (12.0.4237.0)。

我希望，以前没有人问过这个问题...

试试这个:

这里没有问题，DATE 按预期工作

SET LANGUAGE ENGLISH;
DECLARE @dt DATE='2017-01-13'; 
SELECT @dt;
SELECT CAST('2017-01-13' AS DATE);
SELECT CONVERT(DATE,'2017-01-13'); --no culture / format specified
GO
SET LANGUAGE GERMAN;
DECLARE @dt DATE='2017-01-13';
SELECT @dt;
SELECT CAST('2017-01-13' AS DATE);
SELECT CONVERT(DATE,'2017-01-13'); 

但现在用 DATETIME 检查同样的情况

--No problem here:
SET LANGUAGE ENGLISH;
DECLARE @dt DATETIME='2017-01-13'; 
SELECT @dt;
SELECT CAST('2017-01-13' AS DATETIME);
SELECT CONVERT(DATETIME,'2017-01-13'); 
GO

--breaks, due to the "13" and would deliver a wrong result (even worse), if the "day" was not more than "12":
SET LANGUAGE GERMAN;
DECLARE @dt DATETIME='2017-01-13'; 
SELECT @dt;
SELECT CAST('2017-01-13' AS DATETIME);
SELECT CONVERT(DATETIME,'2017-01-13'); 

这是一个错误、目的还是只是肮脏？

Answer 1

DATETIME(旧类型)的 ISO-8601 在某种程度上被“破坏”或“适应”(取决于您将其视为错误还是功能) - 您需要使用YYYYMMDD(没有任何破折号)使其无论语言设置如何都可以工作。

对于 DATE 或 DATETIME2(n) 数据类型，此问题已得到修复，并且“正确的”ISO-8601 格式 YYYY-MM-DD code> 始终会被正确解释。

-- OK because of "adapted" ISO-8601
SET LANGUAGE GERMAN;
DECLARE @dt DATETIME='20170113'; 

SELECT @dt;

SELECT CAST('20170113' AS DATETIME);
SELECT CONVERT(DATETIME, '20170113'); 

-- OK because of DATETIME2(n)
SET LANGUAGE GERMAN;
DECLARE @dt2 DATETIME2(0) = '2017-01-13'; 

SELECT @dt2;

SELECT CAST('2017-01-13' AS DATETIME2(0));
SELECT CONVERT(DATETIME2(0), '2017-01-13'); 

这是 DATETIME 类型的一个怪癖(而且不是唯一的......) - 只需注册它，了解它 - 然后继续(意思是:不要使用 DATETIME 不再 - 使用 DATE 或 DATETIME2(n) 代替 - 更好用!):-)