Luchando contra el tipo fecha de SQL Server

Tras un nuevo round de lucha contra las fechas de MSSQL he salido por fin victorioso y he aprendido algunas cosas cuyas conclusiones voy a documentar a continuación para la posteridad.

MSSQL apesta.  Le faltan muchas cosas que acostumbra uno a utilizar con bases de datos mas sencillas como MySQL.  Por ejemplo: cómo hago un ENUM ?  como hago un DATETIME ? como hago …?

La arquitectura de la conexión es un cuento un poco mas largo.  El servidor de base de datos es un Windows XP con un MSSQL 7.0 mientras que el servidor web es un Linux OpenSuse que conecta el PHP5 al motor de base de datos a través de FreeTDS.

Desde hace unos días para acá el formato de fecha se modificó mágicamente, ya no aparecía 13/02/2009 13:13:31 (DMY) sino feb 13 2009 13:13.  Este también fue el primer problema que tuve alguna vez con MSSQL al rededor del 2002.  En esa época lo solucioné con el modificador SET DATEFORMAT, sin embargo esta vez no fue suficiente.

Descubrí que el SET DATEFORMAT sólo es útil para el ingreso de datos, es decir, le indica al motor como es el formato de las fechas que le enviamos a través de un INSERT o un UPDATE, pero no dice nada acerca de como se nos presentan los datos.  Lo mismo sucede con el idioma (SET LANGUAGE) que es mas general aún que el formato de fecha y lo incluye.

Después de muchos experimentos y pruebas encontré que la presentación de las fechas podía ser manipulada desde el servidor Linux, que en este caso actua como cliente de la base de datos mediante la configureción del FreeTDS.

El el archivo /usr/local/freetds/etc/locales.conf es necesario modificar la sección [default] para incluír la siguiente línea especificando el formato de las fechas.

date format = %d/%m/%Y %H:%M:%S

El formato de los campos es el mismo de strftime.  Con el formato propuesto la fecha aparece como DD/MM/AAAA HH:MM:SS utilizando el horario militar.  Es necesario reiniciar Apache para que el cambio sea tomado en cuenta.

$ sudo service apache2 restart

Como mencioné anteriormente, la modificación del DATEFORMAT o en su defecto del LANGUAGE, nos permiten garantizar que la aplicación reciba correctamente los datos tipos fecha de manera independiente a como fue instalado el MSSQL o se haya realizado la configuración regional del servidor.  Para esto terminé agregando las siguientes líneas al constructor de la superclase de los controladores de Kohana, es decir, en un sitio donde se pueda garantizar que siempre se ejecuta antes que cualquier otro código del sistema suceptible de acceder a la base de datos.

$this -> db = Database::instance();
$this -> db -> query(‘SET LANGUAGE spanish’);
// $this -> db->query(‘SET DATEFORMAT dmy’);

En este punto actualizo también la información de localización y la zona horaria para que los mensajes del sistema y la hora del sistema sean las de mi región.  Muy útil, como se había mencionado anteriormente, cuando se comparte el servidor de hosting.

setlocale(LC_ALL, “es_CO”);
putenv(“TZ=America/Bogota”);

Leave a Reply

Your email address will not be published. Required fields are marked *