sql-server – 什么日期/时刻笔墨名目是LANGUAGE和DATEFORMAT安

很轻易证明,因为SET LANGUAGE,SET DATEFORMAT或登录的默认说话,除了以下两种名目之外的很多日期/时刻名目都轻易被误解：

yyyyMMdd                 -- unseparated,date only
yyyy-MM-ddThh:mm:ss.fff  -- date dash separated,date/time separated by T

纵然是没有T的这种名目也也许看起来像有用的ISO 8601名目,但它在几种说话中失败：

DECLARE @d varchar(32) = '2017-03-13 23:22:21.020';

SET LANGUAGE Deutsch;
SELECT CONVERT(datetime,@d);

SET LANGUAGE Fran?ais;
SELECT CONVERT(datetime,@d);

功效：

Die Spracheneinstellung wurde auf Deutsch ge?ndert.

Msg 242,Level 16,State 3

Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert au?erhalb des gültigen Bereichs.

Le paramètre de langue est passé à Fran?ais.

Msg 242,State 3

La conversion d’un type de données varchar en type de données datetime a créé une valeur hors limites.

此刻,这些失败就像在英语中我已经转换了月份和日期一样,以拟定yyyy-dd-mm的日期组件：

DECLARE @d varchar(32) = '2017-13-03 23:22:21.020';

SET LANGUAGE us_english;
SELECT CONVERT(datetime,@d);

功效：

Msg 242,State 3

The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

(这不是Microsoft Access,这对你来说很“好”,并为你修复了转置.并且,在某些环境下,行使SET DATEFORMAT ydm会产生相同的错误; – 它不只仅是一种说话,它只是更多这些损坏产生的常见环境 – 并不老是被留意到,由于偶然它们不是错误,只是8月7日变为7月8日而没有人留意到.)

那么,题目是：

既然我知道有一堆不安详的名目,那么在给定任何说话和日期名目组合的环境下,是否尚有其他名目是安详的？

办理要领

yyyyMMdd                 -- unseparated,date/time separated by T

可是,最近我留意到第三种名目同样不受任何说话或日期名目配置的影响：

yyyyMMdd hh:mm:ss.fff    -- unseparated date,no T separator

TL; DR：这是究竟.对付datetime和smalldatetime.

继承阅读更长的版本,并得到尽也许多的证据.

有一个裂痕表明白这个 – 固然首要的文本主体没有认可yyyyMMdd ……：作为一种安详的转换说话或日期名目表明的名目,有一点恍惚声名这样的字符串的日期部门不是按照dateformat配置验证：

07001

凡是环境下,只必要记录文档即可.你可以说我有点猜疑.这里的说话也暗昧不清 – 它只是声明这是关于日期和时刻的组合,而不是明晰地挪用空格(也许是回车,对付我所知道的全部).它还说它不是多说话,这意味着它也许在某些说话中失败,但我们很快就会发明这也是不正确的.

以是我开始证明没有说话/日期名目标组合可以使这种特定的名目失败.

起首,我为每种说话建设了一小块动态SQL：

EXEC sys.sp_executesql @sql,N'@lang sysname',N'us_english';

这发生了34行输出,如下所示：

EXEC sys.sp_executesql @sql,N'us_english';
EXEC sys.sp_executesql @sql,N'Deutsch';
EXEC sys.sp_executesql @sql,N'Fran?ais';
EXEC sys.sp_executesql @sql,N'日本語';
...
EXEC sys.sp_executesql @sql,N'简体中文';
EXEC sys.sp_executesql @sql,N'Arabic';
EXEC sys.sp_executesql @sql,N'???';
EXEC sys.sp_executesql @sql,N'norsk (bokm?l)';

我将该输出复制到一个新的查询窗口,在它上面,我天生了这个代码,但愿在至少一个案例中实行将统一日期(3月13日)转换为第13个月的第3天：

DECLARE @sql nvarchar(max) = N'
SET LANGUAGE @lang;
SET DATEFORMAT ydm;
SELECT @@LANGUAGE,CONVERT(datetime,''20170313 23:22:21.020'');';

不,每种说话都可以在ydm找到.我也实行了全部其他名目,以及每个日期/时刻数据范例.每次都有34次乐成转换到3月13日.

以是,我确实向@AndriyM和@ErikE认可,确实存在第三种安详名目.我将在将来的帖子中记着这一点,可是我已经在许多处所敲响了关于其他两小我私人的鼓声,我此刻不规划将它们所有追捕并更正它们.

通过扩展,你会以为这个是安详的,但没有：

yyyyMMddThh:mm:ss.fff    -- unseparated date,T separator

我以为在每种说话中,这将发生相等于：

Msg 241,State 1,Line 8

Conversion failed when converting date and/or time from character string.

为了完备起见,有第四种安详名目,但只有转换为较新的日期/时刻范例(date,datetime2,datetimeoffset)才是安详的.在这些环境下,说话配置不会滋扰：

yyyy-MM-dd hh:mm:...

可是,我凶猛提议不要行使它,由于它只合用于较新的范例,并且按照我的履历,旧的范例如故大量行使.为什么在其他处所(或现实上在沟通的代码中,假如数据范例产生变革)有破折号你必需删除它们？

SET LANGUAGE Deutsch;
DECLARE @dashes char(10) = '2017-03-07 03:34';
DECLARE @d date = @dashes,@dt datetime = @dashes,@dt2 datetime2 = @dashes;

SELECT DATENAME(MONTH,@d),DATENAME(MONTH,@dt),@dt2);

纵然给出沟通的源字符串,转换也会发生完全差异的功效：

M?rz    Juli    M?rz

合用于datetime的名目(yyyyMMdd)也将始终合用于日期和其他新范例.以是,恕我直言,只是老是行使它.而且给定了具有日期/时刻的范例的第三种名目(yyyyMMdd hh：…),这现实上应承您越发同等 – 纵然日期组件老是轻微不那么可读.

此刻,当我评论日期的字符串暗示时,我将耗费几年时刻,给以或接管,养成演示三种安详名目标风俗.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!