SQL server e ISO 8601

Più che di .NET, finisco sempre a parlare di SQL server in questi giorni... ma questo tuning del DB mi sta facendo scoprire un bel po di cosette!

A dire il vero questo problema l'avevo già incontrato un po di tempo fa, ma l'avevo rimosso, ora l'ho ritrovato tra le email e lo ripropongo: come molti di voi sanno, l'ISO 8601 dovrebbe definire uno standard per rappresentare le date in modo da evitare problemi di comprensione ma, soprattutto, di interazione con il fantomatico db.
Purtroppo, quello che ho scoperto è che per SQL server non esiste un vero e proprio formato ISO, ma reinterpreta comunque l'ingresso a seconda dei language settings dell'utente con cui ci si logga nel db! Quindi, se l'utente ha il linguaggio inglese, va tutto bene, se invece ha un linguaggio diverso (tedesco, italiano, russo, etc), sql server reinterpreta il formato e si aspetta YYYY-DD-MM, generando ovviamente un errore di conversione.

Potete anche riprovare voi sul vostro query analyzer questo comportamento con due semplici select su una tabella che abbia un campo data:

SET LANGUAGE english
GO
SELECT * FROM Tabella WHERE Campo = '2005-10-22' --Tutto Ok
GO
SET LANGUAGE italian
GO
SELECT * FROM Tabella WHERE Campo = '2005-10-22' -- Errore di conversione
GO

Questo mi ha particolarmente sconvolto, e mi ha dato una ragione in più per picchiare le mie "scimmie da codice" quando provano a non usare i parameters, ma più che altro è lo sconvolgimento che prevale.
Fin'ora come soluzione cambio i language settings del login con cui entro in SQL server, ma vorrei tanto che qualcuno mi smentisse/mi desse un'altra soluzione (Senza andare a toccare syslanguages :p).

Print | posted on venerdì 14 ottobre 2005 14.52

Comments on this post

# re: SQL server e ISO 8601

Requesting Gravatar...
Il formata delle date indipendente dalla lingua dell'utente corrente di sql server è:

yyyymmdd

oppure

{d 'yyyy-mm-dd'}

Ad esempio:

SELECT * FROM Tabella WHERE Campo = '20051022'
SELECT * FROM Tabella WHERE Campo = {d '2005-10-22'}

nel BOL di SQL sono chiaramente specificati tutti i formati per la scrittura di codice internazionale (cerca "Scrittura di istruzioni Transact-SQL internazionali")

Ciao
Left by Antonio "tdj" Catucci on ott 14, 2005 3.52

# re: SQL server e ISO 8601

Requesting Gravatar...
Perfetto, questo mi chiarifica le cose, ma vorrei capire come mai di default SQL server reinterpreta il formato ISO e devo dargli un'escape per permettere che prenda la stringa di ingresso nel formato giusto... IMHO è ridicolo, visto che non esiste nessun paese che scrive la data in formato YYYY-DD-MM che io sappia!
Left by Alessandro Ghizzardi on ott 14, 2005 4.28

# re: SQL server e ISO 8601

Requesting Gravatar...
Lo standard specifica diverse rappresentazioni e diversi formati, SQL Server ne supporta solo 2 ed anche i BOL sono imprecisi.

Dal BOL: per le date senza la parte oraria, SQL Server supporta la rappresentazione troncata, ma solo il formato "basic" YYMMDD (rif. ISO 8601 2nd edition al punto 5.2.1.3), cioé quello senza il carattere "-" come separatore.

SET LANGUAGE english
GO
SELECT CAST('051022' AS datetime)
GO

SET LANGUAGE italian
GO
SELECT CAST('051022' AS datetime)

In realtà supporta anche la rappresentazione completa, sempre solo nel formato "basic" YYYYMMDD (rif. ISO 8601 2nd edition al punto 5.2.1.1).

SET LANGUAGE english
GO
SELECT CAST('20051022' AS datetime)
GO

SET LANGUAGE italian
GO
SELECT CAST('20051022' AS datetime)

Per le date comprensive di parte oraria, invece, non supporta nemmeno la rappresentazione completa, ma solo versione ridotta e solo il formato "extended" YYYY-MM-DDTHH:MM:SS" (rif. ISO 8601 2nd edition al punto 5.2.1.1), manca la zona.

SET LANGUAGE english
GO
SELECT CAST('2005-10-22T00:00:00' AS datetime)
GO

SET LANGUAGE italian
GO
SELECT CAST('2005-10-22T00:00:00' AS datetime)

Tra l'altro in quest'ultimo caso i BOL specificano come supporto allo standard il formato YYYY-MM-DDTHH:MM:SS.MMM quando il formato (almeno la copia che ho sottomano) non dice nulla per quanto riguarda i millisecondi.

L'uso del dell'escape non mi piace perché è legato alle API (infatti nei BOL dicono di usarli per ADO, OLE-DB ed ODBC) mentre per gli script/procedure/trigger T-SQL dicono di usare la funzione di CONVERT).

Detto questo, se capisco perché ci sia ambiguita per il formato XX-XX-XX (potrebbe essere sia ISO esteso YY-MM-DD che italiano DD-MM-YY), e quindi perché è necessario specificare una lingua di riferimento, non capisco perché dovrebbe esserci ambiguità per il formato XXX-XX-XX (se non me ne sono perso uno potrebbe essere solo quello ISO YYYY-MM-DD perché quello italiano sarebbe DD-MM-YYYY).

Comunque questo è il supporto (documentato) che viene fornito, quindi usa una delle due date ISO supportate e vivi felice :-)
Left by Gianluca Hotz on ott 14, 2005 5.50

# re: SQL server e ISO 8601

Requesting Gravatar...
Maledetto cut&paste e rebelott dello standard :@ questo:

Per le date comprensive di parte oraria, invece, non supporta nemmeno la rappresentazione completa, ma solo versione ridotta e solo il formato "extended" YYYY-MM-DDTHH:MM:SS" (rif. ISO 8601 2nd edition al punto 5.2.1.1), manca la zona.

dovrebbe va corretto in:

Per le date comprensive di parte oraria, invece, supporta la rappresentazione completa, e solo il formato "extended" YYYY-MM-DDTHH:MM:SS" (rif. ISO 8601 2nd edition al punto 5.4.1), manca la zona e viene assunto l'orario locale.
Left by Gianluca Hotz on ott 14, 2005 5.56

# re: SQL server e ISO 8601

Requesting Gravatar...
Questo dovrebber esserti di aiuto:
http://blogs.ugidotnet.org/nettools/articles/9541.aspx
:-)
Left by Davide Mauri on ott 14, 2005 6.44

# re: SQL server e ISO 8601

Requesting Gravatar...
Infatti neanche io capisco come possa essere possibile che un YYYY-MM-DD senza cast possa essere visto come YYYY-DD-MM cambiando i default settings.
Cmq è stata una sottigliezza mia che non ho fatto le prove e mi sono fidato alla cieca, vorrà dire che da ora in poi utilizzerò il formato iso YYYYMMDD e vivo felice... ma non so se dormire tranquillo pensando a tutte la applicazioni li nel mondo in cui ho usato con ASP 3.0 YYYY-MM-DD e che magari tra un po necessitano di reinstallazione... che so, magari cambiando i language settings :)
Left by Alessandro Ghizzardi on ott 15, 2005 2.22

# re: SQL server e ISO 8601

Requesting Gravatar...
Io faccio cosi:

SELECT * FROM Tabella WHERE Campo= CONVERT(DATETIME, '10/20/2005', 101)

Il terzo parametro della funzione CONVERT identifica la lingua che il server DEVE utilizzare per la query.

Left by David on ott 20, 2005 2.14

# re: SQL server e ISO 8601

Requesting Gravatar...
SELECT * FROM Tabella WHERE Campo= CONVERT(DATETIME, '10/20/2005', 101)


Chiaramente il 101 identifica il formato inglese quindi, la data deve essere inserita nel formato MM/DD/YYYY

Left by David on ott 20, 2005 2.19

# re: SQL server e ISO 8601

Requesting Gravatar...
Scusate, ma alla fine qual'è la soluzione vincente?
Io ho provato ad inviargli la data in formato Iso, su mdb va benissimo ma su MsSql me la gira!
Perche fanno queste cazzatone in casa microsoz ????

Saluti
Acar
Left by Acar on feb 09, 2006 9.05

# re: SQL server e ISO 8601

Requesting Gravatar...
YYYYMMDD è il formato corretto, funziona perfettamente in quanto è sempre formato standard!
Left by Alessandro Ghizzardi on feb 09, 2006 9.47

# re: SQL server e ISO 8601

Requesting Gravatar...
ed io gliela passo proprio cosi

dData = sAnno & "/" & sMese & "/" & sGiorno

rSql = "Insert INTO News (nTitolo, nIntestazione, nTesto, nData) VALUES ('"& SQLEncrypt(sTitolo) &"', '"& SQLEncrypt(sIntestazione) &"', '"& SQLEncrypt(sTesto) &"', '"& dData &"')"

In access mi funziona su sql no!
Bho

Grazie Comunque
Left by Acar on feb 09, 2006 9.58

# re: SQL server e ISO 8601

Requesting Gravatar...
Non hai capito, non yyyy/mm/dd, proprio yyyymmdd.. senza le "/" quindi non 2006/02/07 ma 20060207

Left by Alessandro Ghizzardi on feb 09, 2006 10.18

# Buy soma from mexico online.

Requesting Gravatar...
Buy soma online order soma and get cheap soma. Buy soma. Buy soma online without rx. Buy soma online. Buy soma bloghoster.
Left by Buy soma from canada. on ott 30, 2008 7.43

# Buy watson brand soma.

Requesting Gravatar...
Buy soma cod. Buy soma. Buy soma online. Buy soma watson brand 180 tablets. Buy soma online without rx. Buy soma bloghoster. Http pills.viptemplates.com p buy soma.
Left by Buy soma watson brand 180 tablets. on ott 31, 2008 4.14

# Ohio valley dating.

Requesting Gravatar...
Ohio valley dating.
Left by Ohio valley dating. on nov 04, 2008 1.22

# Adult cam chat dating direct lin.

Requesting Gravatar...
Adult cam chat dating direct lin. Adult cam dating.
Left by Adult cam chat dating direct lin. on nov 04, 2008 8.37

# Online divorced dating websites.

Requesting Gravatar...
Online dating websites. Online divorced dating websites.
Left by Online divorced dating websites. on nov 04, 2008 4.24

# Free internet dating sites.

Requesting Gravatar...
100 free internet dating. Free christian internet dating.
Left by Completely free internet dating. on nov 05, 2008 4.50

# Online divorced dating websites.

Requesting Gravatar...
Online dating websites. Free online dating websites....totally free. Good online dating websites.
Left by Good online dating websites. on nov 06, 2008 3.23

# Free black men white women dating sites.

Requesting Gravatar...
Dating site where white woman can meet black men. White woman tired of dating black men. Black women white men dating. Black women dating white men. Asian men dating black women. Dating for black men. Black women dating italian men. Hispanic men black women dating.
Left by Asian men dating black women. on nov 06, 2008 2.06

# Bbw dating bbw personals bbw plus size singles.

Requesting Gravatar...
Bbw personals online dating and personal ads. Free bbw singles dating personals site. Bbw seek bbw personals and dating. Bbw dating personals online at bbwdatelink com. Bbw dating bbw personals bbw plus size singles. Bbw dating personals.
Left by Bbw personals online dating and personal ads. on nov 06, 2008 5.30

Your comment:

 (will show your gravatar)
 
Please add 6 and 8 and type the answer here: