En laissant de coté le « smalldatetime », un seul type est disponible avec SQL Server 2005 pour stocker une date : c'est le type « datetime ». « datetime » peut stocker une date de « 1753-01-01 » à « 9999-12-31 ». Si l'on compare à la structure « DateTime » du Framework .Net qui peut contenir une date de « 0001-01-01 » à « 9999-12-31 », on se rend compte qu'il faut faire très attention lors des opérations d'insertion ou d'update : la colonne avec « datetime » ne supportera pas une valeur de « DateTime.MinValue » par exemple !

Ce qui est vrai avec SQL Server 2005 et « datetime » est aussi vrai avec sur SQL Server 2008. Mais SQL Server 2008, est livré avec un nouveau type: « datetime2(n) » N étant la précision en dessous de la seconde. Voici le lien vers MSDN pour plus de détail. Ce nouveau type a l'énorme avantage d'avoir le même intervalle de valeur que notre structure « DateTime ». Nous pouvons donc sans problème y sauvegarder « DateTime.MinValue » et « DateTime.MaxValue » :

Autre nouveauté de SQL Server 2008 : « datetimeoffset ». Ce type est l'équivalent de la structure DateTimeOffset du Framework. Elle contient :

• Une date, de type « DateTime »
• Un décalage par rapport à GMT, de type « TimeSpan »

Voici une utilisation simple de « DateTimeOffset » :Le résultat est le suivant :
Now: 15/08/2008 11:33:16 +02:00, GMT Now: 15/08/2008 09:33:16 +00:00, True

Coté base de données, l'affichage est équivalent :L'avantage de ce type est de gérer nativement le temps local et le temps universel : il n'est pas nécessaire, contrairement à « datetime » ou « datetime2 » de forcer le stockage du temps en UTC pour avoir un référentiel unique, « datetimeoffset » le fait pour nous. La seule contrainte est de manipuler une structure « DateTimeOffset » au lieu d'un « DateTime » lors des interactions avec la base. Si le temps doit être sauvegardé en temps universel il faut donc alors privilégier « datetime2 » à « datetime ».