sql server - Date conversion and culture: Difference between DATE and DATETIME -


i've written lot of answers date or datetime conversions strings. living in german speaking country, i'm used deal non-us_english date formats , i'm used use secure literals (i prefere odbc format) , never use convert without third parameter. not question , please not provide answers in direction...

very 1 can read, format yyyy-mm-dd standard (iso8601, ansi, whatever) , therefore culture independant.

today had edit one of these older answers, had stated there, observed behaviour depending on else.

the question is:

why (if there reason) there difference between date , datetime?

... @ least in environmen, sql server 2014 (12.0.4237.0) @ moment.

i hope, not asked before...

try this:

no problems here, date works expected

set language english; declare @dt date='2017-01-13';  select @dt; select cast('2017-01-13' date); select convert(date,'2017-01-13'); --no culture / format specified go set language german; declare @dt date='2017-01-13'; select @dt; select cast('2017-01-13' date); select convert(date,'2017-01-13');  

but check same datetime

--no problem here: set language english; declare @dt datetime='2017-01-13';  select @dt; select cast('2017-01-13' datetime); select convert(datetime,'2017-01-13');  go  --breaks, due "13" , deliver wrong result (even worse), if "day" not more "12": set language german; declare @dt datetime='2017-01-13';  select @dt; select cast('2017-01-13' datetime); select convert(datetime,'2017-01-13');  

is bug, purpose or grubbiness?

the iso-8601 datetime (the older type) somehow "broken" or "adapted" (depending on whether @ bug or feature) - need use yyyymmdd (without dashes) make work irrespective of language settings.

for date or datetime2(n) datatypes, has been fixed , "proper" iso-8601 format yyyy-mm-dd interpreted correctly.

-- ok because of "adapted" iso-8601 set language german; declare @dt datetime='20170113';   select @dt;  select cast('20170113' datetime); select convert(datetime, '20170113');   -- ok because of datetime2(n) set language german; declare @dt2 datetime2(0) = '2017-01-13';   select @dt2;  select cast('2017-01-13' datetime2(0)); select convert(datetime2(0), '2017-01-13');  

it's quirk of datetime type (and not one....) - register it, know - , move on (meaning: don't use datetime anymore - use date or datetime2(n) instead - nicer work with!) :-)


Comments

Popular posts from this blog

python - Operations inside variables -

Generic Map Parameter java -

arrays - What causes a java.lang.ArrayIndexOutOfBoundsException and how do I prevent it? -