Enregistrement de dates dans SQLServer

Le format YYYY-MM-DD est sans ambiguïté, ce qui signifie que SQL Server ne confondra pas le mois et le jour lors de la conversion d'une valeur de string en DATETIME . (Je n'ai jamais rencontré de problème avec une conversion implicite utilisant ce format en utilisant l'année à quatre numbers.)

Le moyen le plus sûr (et le plus pratique) de stocker des valeurs de date dans SQL Server consiste à utiliser le type de données DATETIME.

Utilisez la fonction CONVERT pour spécifier explicitement les formats d'input et de sortie lors de la conversion entre DATETIME et les strings.

Documentation SQL Server 2005 sur les valeurs d'argument de style CONVERT:

http://msdn.microsoft.com/en-us/library/ms187928(SQL.90).aspx

Pour convertir une représentation de string en type de données DATETIME:

 select CONVERT(datetime, '2009-06-03', 20) 

Le premier argument est le type de données à convertir, le deuxième argument est l'expression à convertir, le troisième argument est le style .

(Le style 20 est le format ODBC Canonical = 'YYYY-MM-DD HH:MI:SS' (24 heures)

[SUIVRE]

Pour convertir une expression DATETIME (par exemple, getdate () en VARCHAR au 'YYYY-MM-DD' :

 select CONVERT(varchar(10), getdate(), 20) 

Notez que spécifier varchar (10) vous donne seulement les 10 premiers caractères du format etnire 'YYYY-MM-DD HH:MM:SS' .

[/SUIVRE]

Quant à savoir ce qui détermine les formats par défaut, ça va être de la search. Nous évitons les problèmes causés par les formats par défaut en spécifiant les formats.

Voir SET DATEFORMAT . La 'culture' SQL est définie par SET LANGUAGE au niveau d'une session. SQL Server possède ses propres parameters de format de date, indépendants du operating system hôte. C'est pour plusieurs raisons: la conformité ANSI, pour empêcher les changements du operating system d'affecter les applications en utilisant la database hébergée sur cet hôte et non la moindre est la compatibilité, le SQL est antérieur à l'OS en cours d'exécution.

Je recommand de stocker toutes les dates en heure UTC quand ils sont placés dans la database. Ce sera cohérent de cette façon.

Le stockage de dates comme celui-ci semble bien fonctionner …

 YYYY-MM-DD 

Gardez à l'esprit que DATA n'est pas sa présentation. Dans ce cas, DATA est une DATE ou DATETIME, quelle que soit la manière dont vous les affichez.
En ce qui concerne l'insertion / la mise à jour / la comparaison des valeurs datetime, je cite le BOL:

Lorsque vous spécifiez des dates dans des comparaisons ou pour des instructions INSERT ou UPDATE, utilisez des constantes interprétées de la même manière pour tous les parameters de langue: ADO, OLE DB et ODBC doivent utiliser les clauses d'échappement ODBC, date et heure suivantes:
{ts 'aaaa-mm-jj hh: mm: ss [.fff]'} tels que: {ts '1998-09-24 10:02:20'}
{d 'aaaa-mm-jj} tels que: {d' 1998-09-24 '}
{t 'hh: mm: ss'} tels que: {t '10: 02: 20 '}

Je peux vous assurer que, si vous utilisez ce format, ils fonctionneront toujours, quel que soit le lieu de votre server

Je suis un peu conservateur dans ces domaines, mais je préfère utiliser des champs Année / Mois / Jour distincts dans la table plutôt qu'un champ Date qui utilise un type de données spécifique au SGBD. Cela prend certainement plus de place, mais le manque d'ambiguïté et la portabilité accrue en valent la peine.

Le prix que vous payez est que vous n'obtenez pas d'arithmétique et de sorting date / heure, mais c'est assez facile à faire vous-même ou par une clause "ORDER BY" un peu plus complexe.

Je suis d'accord avec le conseil de spencer7593, mais s'il vous plaît soyez conscient que l'utilisation de cast ou de convertir sans un format peut donner des résultats inattendus. Cette requête T-SQL renvoie 12, pas 1.

 set language British select month(CAST('2016-01-12' AS datetime))