sql >> Base de Datos >  >> RDS >> Sqlserver

¿Cómo decide SQL Server el formato para la conversión implícita de fecha y hora?

Esto puede depender de una variedad de factores:la configuración regional del sistema operativo, el idioma del usuario actual y la configuración del formato de fecha. De forma predeterminada, Windows usa US English y la configuración del usuario es US English y MDY .

Pero aquí hay algunos ejemplos para mostrar cómo esto puede cambiar.

El usuario está utilizando la configuración de idioma BRITÁNICO:

-- works:
SET LANGUAGE BRITISH;
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04/13/2012');
GO

(Error)

El usuario está usando Français:

-- works:
SET LANGUAGE FRENCH;
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04/13/2012');
GO

(Error)

El usuario vuelve a utilizar Français:

SET LANGUAGE FRENCH;

-- fails (proving that, contrary to popular belief, YYYY-MM-DD is not always safe):
SELECT CONVERT(DATETIME, '2012-04-30');
GO

(Error)

El usuario está usando DMY en lugar de MDY:

SET LANGUAGE ENGLISH;
SET DATEFORMAT DMY;

-- works:
SELECT CONVERT(DATETIME, '30-04-2012 19:01:45');

-- fails:
SELECT CONVERT(DATETIME, '04-30-2012');
GO

(Error)

Su mejor opción, siempre, es usar formatos de fecha estándar ISO, no regionales, seguros e inequívocos. Los dos que normalmente recomiendo son:

YYYYMMDD                  - for date only.
YYYY-MM-DDTHH:MM:SS[.mmm] - for date + time, and yes that T is important.

Ninguno de estos falla:

SET DATEFORMAT MDY;
SET LANGUAGE ENGLISH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET LANGUAGE FRENCH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET LANGUAGE BRITISH;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');
SET DATEFORMAT DMY;
SELECT CONVERT(DATETIME, '20120430');
SELECT CONVERT(DATETIME, '2012-04-30T19:01:45');

Por lo tanto, recomiendo encarecidamente que, en lugar de permitir que los usuarios escriban en formatos de fecha de texto libre (o que usted mismo use formatos poco confiables), controle sus cadenas de entrada y asegúrese de que se adhieran a uno de estos formatos seguros. Entonces, no importará qué configuración tenga el usuario o cuál sea la configuración regional subyacente, sus fechas siempre se interpretarán como las fechas previstas. Si actualmente permite que los usuarios ingresen fechas en un campo de texto en un formulario, deje de hacerlo e implemente un control de calendario o al menos una lista de selección para que finalmente pueda controlar el formato de cadena que se pasa de vuelta a SQL Server.

Para conocer algunos antecedentes, lea la "La guía definitiva de los tipos de datos de fecha y hora" de Tibor Karaszi. tipos de datos" y mi publicación "Malos Hábitos para eliminar:Manejo incorrecto de consultas de fechas/rango".