由于 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, Level 16, 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);
结果：
消息 242，级别 16，状态 3
将 varchar 数据类型转换为 datetime 数据类型导致值超出范围。
（这不是 Microsoft Access，它对您来说“很好”并为您修复了转置。此外，在某些情况下可能会发生类似的错误SET DATEFORMAT ydm;- 这不仅仅是语言问题，这只是更常见的情况，其中这些破损发生 - 并不总是被注意到，因为有时它们不是错误，只是 8 月 7 日变成了 7 月 8 日，没有人注意到。）
所以，问题：
既然我知道有一堆不安全的格式，那么在给定任何语言和日期格式组合的情况下，还有其他安全的格式吗？
