¿Como manejar las fechas en Sql Server?

Esta pregunta debe ser una de las que mas se hacen. Este artículo tratara de explicar
como usar las Fechas en Sql Server y que cosas debemos tomar en consideración.
Antes de empezar voy a tratar de explicar que son las Fechas para SqlServer:
Este mismo tiene básicamente dos tipos de datos donde se pueden almacenar fechas
propiamente dichas: Datetime y SmallDateTime, en este cuadro veremos las diferencias
entre estos dos tipos de Datos.

DateTime Valores de Fecha y Hora que están

comprendidos entre 1/1/1763 y
31/12/9999. La hora se expresa con una
exactitud de hasta 1/300 de segundo
SamallDateTime Valores de Fecha y Hora que están
comprendidos entre 1/1/1900 y 6/6/2079.
El grado de precisión de la hora llega
hasta el minuto

Bien ahora conocemos los tipos de datos de nuestro motor, pero la gran pregunta, ¿Cómo
Guarda internamente Sql Server las Fechas? ¿Lo hace en formato MM/DD/YYY o lo hará en
DD/MM/YYYY?, bueno lamento decirles que nuestro motor siempre guarda las fechas de una
sola forma y no esta referida a ningún formato (Americano,Español,Japones) como recién
mencione
¿Entonces? Bueno Sql Server guarda las fechas DateTime como enteros de 4 Bytes (Los primeros
4 Bytes almacenan la Fecha y los otros 4 Bytes la Hora), en SmallDatetime como tienen menor
precisión en lugar de ser dos grupos de 4 son dos grupos de 2.

Ahora sabemos también no solo que tipos de datos tenemos para guardar nuestras fechas y
horas sino que también como las guarda el motor realmente.
Con todo esto me estoy preguntando, ¿Entonces porque cuando hago algún Select me trae las
fechas en un formato X (como por ejemplo el Americano)?
Claro esto es así porque leer las fechas en grupos de Bytes no es muy elegante que digamos y
nuestros usuarios no estarían muy contentos.
Bueno ahora entonces tenemos un dilema, ya que cuando quiera hacer una consulta por
ejemplo entre fechas deba primero saber que tipo de Formato usar (Americano,Español,etc) ya
que no es lo mismo 10-01-2004 (donde 10 es el día y 01 el mes) a 10-01-2004 (Donde 10 es el mes
y 01 el día).

Una de las técnicas que veo que mas se usan es aplicar siempre un formato y con eso parece
estar la cosa controlada, claro que no es para nada así ya que el formato dependerá de que
idioma tenga definido nuestro usuario por lo cual esto nos puede traer muchas complicaciones.

Entonces, ¿Cómo hacer una consulta de fechas en un formato y no morir en el intento?, bueno
acá hay una solución muy interesante, y es el uso del Standard ANSI para las fechas, este
Standard esta compuesto así: YYYYMMDD HH:mm:ss’ , si yo empiezo a utilizar este formato
para mis consultas no tendré problemas en ninguna de mis aplicaciones por mas que nuestro
usuario este configurado en Ingles, Español o lo que fuere, ni tampoco si en un Windows tengo
definido en su configuración regional cualquier cosa.

Ahora tenemos un poco de teoría, pero la misma debe ir acompañada con alguna práctica no?
Las cosas hay que demostrarlas para que nos convenzan, por lo menos es mi forma de hacer y
pedir las cosas.
Para nuestro ejemplo utilizaremos la Base de Datos Northwind que ya viene como ejemplo en
nuestro Sql Server, de no tenerla favor de instalarla desde el instalador correspondiente.

Nota: De aquí en adelante usaremos el Analizador de consultas (Query analizer), pero

recordemos que cuando desarrollamos aplicaciones las consultas las hacemos vía la aplicación,
al final del articulo hablaremos un poco mas de este tema.

/* Creamos un usuario donde su idioma predefinido es el Español */

sp_addlogin 'UserFechas','pepe','master','Español'

/* vamos a darle acceso a nuestra Base de Datos Northwind */

use Northwind
GO
sp_grantdbaccess 'UserFechas'
GO

Ahora salimos de nuestro QA (Analizador de Consultas) y volveremos a entrar con este nuevo
usuario que creamos (Recuerden que la autentificación de nuestro motor en este caso debe ser
Mixta y que el uso de cuentas de SqlServer no es aconsejable, sino que hay que tratar de utilizar
la autentificación Windows, pero para hacer el ejemplo mas fácil es que use Autentificación Sql
con un usuario Sql)

Bien lo primero que haremos es verificar que el idioma este en español como lo hemos indicado
anteriormente al usuario, para ello usaremos la siguiente instrucción.

Select @@Language

Este debería ser el resultado luego de ejecutar dicha consulta.

----------------------------------------------------------------------------------------------------------Español

(1 filas afectadas)

Bien ahora usaremos la tabla Orders y haremos la consulta de fechas de dos formas distintas, la
primera usando los formatos como la mayoría esta acostumbrado y la segunda utilizando el
formato ANSI que seria el correcto.

use northwind
go

-- Opcion que estamos acostumbrados a usar

select count(*) from orders where orderdate >='01-08-1997'

-- Opcion con Ansi

select count(*) from orders where orderdate >='19970801'

Bien acá veremos que en ambas consultas nos trae como retorno del Count 460, esto quiere decir
que encontró 460 registros donde su orderdate son mayor o igual al 1 de Agosto de 1997.
Bien ahora cambiaremos el lenguaje de nuestra sesión a ingles y haremos la misma consulta
para ver que sucede:

use northwind
go

/* Cambiamos el lenguaje para esta sesión a Ingles, esta opción no cambia el lenguaje del
Usuario sino que solo la sesión que al cerrarla volverá a tomar la del usuario si
Es que no especifico ningún SET LANGUAGE
*/

SET LANGUAGE us_english

GO

-- Opción que estamos acostumbrados a usar

select count(*) from orders where orderdate >='01-08-1997'

-- Opción con ANSI

select count(*) from orders where orderdate >='19970801'

Como vemos aquí la primer consulta paso de los 460 registros a los 670, porque sucede esto?
Bueno como es ingles ahora la fecha que queremos consultar es realmente
Mayor al 8 de enero de 1997, pero ejecuten la segunda consulta y verán que esta sigue
retornando los 460 originales, pues bien esto es por todo lo que hemos dicho antes y porque es
muy pero muy importante utilizar este tipo de formato (YYYYMMDD hh:mm:ss)

Bien hemos aprendido a usar el formato ANSI para nuestras consultas (Querys) pero eso no es
todo, ahora trataremos de ver algunos ejemplos típicos de búsquedas con fechas para poder
analizar bien estos casos.

Una consulta muy recurrente es: ¿Cómo busco los registros de una fecha en particular ya que
me toma también la hora? Bueno esto es totalmente cierto, si ponemos por ejemplo = ‘20040101’
esto traerá los registros no del día 01 de enero del 2004 totalmente sino aquellos que sean de las
0 Horas, bueno para solucionar esto a mi me gusta usar esta consulta muy simple.

Select * from orders Where orderdate >='19970805' and orderdate < dateadd(dd,1,'19970805')

Como verán primero es que sigo en la misma regla del ANSI y luego utilizo la función Dateadd
para poder a la fecha sumarle un día, con esto logro que no me importe que hora tengan los
registros que me traerá todos los del día 05 de agosto de 1977.

Bien ahora tenemos casi el 90% resuelto de los problemas más habituales con fechas, pero de
todos modos no deberíamos dejar de ver las funciones que están asociadas con la manipulación
de Fechas

Función Determinismo
DATEADD Devuelve un valor datetime nuevo que se basa en la suma de
un intervalo a la fecha especificada.
DATEDIFF Devuelve el número de límites de fecha y hora que hay entre
dos fechas especificadas.
DATENAME Devuelve una cadena de caracteres que representa la parte de
la fecha especificada de la fecha especificada.
DATEPART Devuelve un entero que representa la parte de la fecha
especificada de la fecha indicada..
DAY Devuelve un entero que representa la parte del día de la fecha
especificada.
GETDATE Devuelve la fecha y hora actuales del sistema en el formato
interno estándar de Microsoft® SQL Server™ para los
valores datetime.
GETUTCDATE Devuelve el valor de datetime que representa la hora UTC
actual (Universal Coordinated Time u hora del meridiano de
Greenwich). La hora UTC actual se deriva de la hora local
actual y la configuración de zona horaria del sistema
operativo del equipo en el que se ejecuta SQL Server.
MONTH Devuelve un entero que representa el mes de una fecha
especificada.
YEAR Devuelve un entero que representa la parte de año de la fecha
especificada.

Observaciones: Cuando desarrollamos nuestra aplicación es muy común preguntarnos

si hacer Stores Procedures o directamente que nuestra aplicación envié las sentencias Tsql.
Lo importante destacar en estos casos es saber porque recomiendo el uso de los Stores en lugar
que nuestra aplicación este haciendo los Tsql y pasarlos al motor.
Los Stores deben de ser una de las reinas de los motores y de los DBA  , porque? Simple:
Poner nuestras consultas en Stores nos da como ventajas esto:

1) Mayor optimización para el motor: Este mismo no debe compilar ( a menos que se lo
indiquemos) cada instrucción T-sql, sino que ya la tiene compilada y esto genera mucha
mayor performance. También se da el caso que el Store reside en nuestro servidor por lo
cual el trafico de red es muy inferior al que podemos hacer si mandamos las Tsql desde
nuestro cliente.
2) Seguridad: Los stores no solo son buenos por performance, sino que nos permiten hacer
las operaciones no directamente sobre nuestras tablas: Un ejemplo muy clásico es este:
Tenemos una aplicación de Clientes donde solo queremos que el listado de precios sea
ejecutado por nuestras aplicaciones autorizadas y no que por medio de un Excel el
usuario lo pueda hacer, en este caso si para ese Query usamos un Store, lo que hacemos
es darle permisos a nuestros usuarios solo al Store y no a las tablas, por lo cual para
sacar el Query debe ejecutar el Store 
3) Reutilización de código: El uso de Stores es muy útil para esto, si la consulta de rangos
de fechas para buscar los pedidos en firme de un cliente por ejemplo, la necesitamos en
mas de una aplicación, entonces podemos reutilizar el Store sin problemas
4) Reglas de negocio: En un Store podemos poner reglas de negocio y así que nuestras
aplicaciones se beneficien de ello, ojo con esto, no abusar, yo como regla tengo que si
debo usar cursores o cosas complicadas donde el desempeño este en juego, lo prefiero
hacer en un COM, ahora de no ser así los Stores son muy buenos y óptimos para todo
esto.
Una cosa adicional al uso de Store (mi experiencia nomás), es que si no lo hacemos en Store y lo
ponemos en la aplicación, luego si hay que cambiar algo seguramente debamos recompilar
nuestras aplicaciones y esto es muy doloroso de verdad y difícil de mantener, que pasa con los
Stores? En la mayoría de los casos las modificaciones (si no tienen nuevos parámetros de
entrada o salida) no afectan a la aplicación, en mi experiencia de este tipo son casi la mayoría 

Conclusiones finales:

El uso de las fechas es un gran problema si no lo sabemos entender y nos puede traer
muchos dolores de cabeza de verdad, pero además de esto es muy importante que nuestros
Querys puedan estar en su mayoría (hay casos donde esto no es viable) dentro de Stores
Procedures y saber que Tsql no es un lenguaje de programación ni mucho menos, entonces
usémoslo para lo que fue creado 