É fácil demonstrar que muitos formatos de data/hora diferentes dos dois seguintes são vulneráveis a interpretações errôneas devido a SET LANGUAGE, SET DATEFORMAT ou ao idioma padrão de um login:
yyyyMMdd -- unseparated, date only
yyyy-MM-ddThh:mm:ss.fff -- date dash separated, date/time separated by T
Mesmo este formato, sem o T, pode parecer um formato ISO 8601 válido, mas falha em vários idiomas:
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);
Resultados:
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, Nível 16, Estado 3
La convert d'un type de données varchar en type de données datetime a créé une valeur hors limites.
Agora, estes falham como se, em inglês, eu tivesse transposto o mês e o dia, para formular um componente de data de yyyy-dd-mm:
DECLARE @d varchar(32) = '2017-13-03 23:22:21.020';
SET LANGUAGE us_english;
SELECT CONVERT(datetime, @d);
Resultado:
Msg 242, Level 16, State 3
A conversão de um tipo de dados varchar em um tipo de dados datetime resultou em um valor fora do intervalo.
(Este não é o Microsoft Access, que é "legal" para você e corrige a transposição para você. Além disso, erros semelhantes podem acontecer em alguns casos com SET DATEFORMAT ydm;- não é apenas uma coisa de idioma, esse é apenas o cenário mais comum em que esses quebras acontecem - e nem sempre são notadas porque às vezes não são erros, só que 7 de agosto virou 8 de julho e ninguém percebeu.)
Então, a pergunta:
Agora que sei que existem vários formatos inseguros, existem outros formatos que serão seguros, considerando qualquer combinação de idioma e formato de data?
