Getting Started with Adobe After Effects - Part 6: Motion Blur


Upload Image Close it
Select File

Browse by Tags · View All
sql_server 217
t-sql 211
tsql 116
sqlserver 96
BRH 78
#SQLServer 66
#TSQL 56
SQL Server 34
function 11
SSMS 9

Archive · View All
August 2007 17
August 2010 8
June 2012 7
June 2011 7
November 2007 7
August 2012 6
May 2012 6
November 2011 6
August 2011 6
October 2011 6

Madhivanan's TSQL Blog

Always use Unambiguous date formats in the queries

Sep 6 2012 12:00AM by Madhivanan   

Handling DATETIME values in the queries is often challenging due to various factors which include choosing wrong datatype(VARCHAR instead of DATETIME),formatting in sql,expressing values in regional specific format,removing time part,etc.

Well. Here is the question that came up in a forum.

I have this query:

update table  
set initTime = '2012-08-20 09:30:00.000'  
WHERE id='0124' 

and it says:

conversion from varchar to datetime generated an out of range value.

Can you help me out please?

Ok. What do you think about this question? The date is expressed correctly and as most people think it is unambiguous. Can you simulate the above error? Well. See what happens you do the following

 set dateformat ydm
 select cast('2012-08-20 09:30:00.000'  as datetime)

You get the following error
Msg 242, Level 16, State 3, Line 2
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

So what is the solution? You should learn how to express DATETIME values in an unambiguous ways.

The three true unambiguous date formats are

YYYYMMDD
YYYYMMDD HH:MM:SS
YYYY-MM-DDTHH:MM:SS

The third format has T, the time seperator which seperates TIME from DATE. So when you use YYYY-MM-DD you should use time seperator T to make the format a true unambiguous. Now see what happens when you execute the following 

 set dateformat ydm
 select cast('2012-08-20T09:30:00.000'  as datetime)


It returns the DATETIME value 2012-08-20 09:30:00.000

So you should always use UNAMBIGUOUS date format when expressing DATETIME values in your queries and NEVER worry about how datetime values are internally stored or what the current date format of the server is

I have already explained about DATETIME datatype in four different blog post which are listed below

Understanding Datetime column - Part I
Understanding Datetime column - Part II
Understanding Datetime column - Part III
Understanding Datetime column - Part IV

In particular Part II will explain on how to deal with different date formats and usage of unambiguous date formats

Tags: 


Madhivanan
3 · 39% · 12472
9
 
0
Lifesaver
 
 
 
0
Incorrect



Submit

6  Comments  

  • From a storage perspective, in our system, we always store the date & time information together in a single date-time column. Requirements such as providing only the date or the time portion are realized by the use of computed columns. The formats I generally use are #2 (for legacy systems) & #3 (for the "modern" ones) (i.e. YYYYMMDD HH:MM:SS and YYYY-MM-DDTHH:MM:SS).

    commented on Sep 6 2012 12:44PM
    Nakul Vachhrajani
    4 · 33% · 10680
  • Thanks Nakul. I use YYYYMMDD if I don't need time and if time is needed I use YYYYMMDD HH:MM:SS

    commented on Sep 6 2012 11:55PM
    Madhivanan
    3 · 39% · 12472
  • I use YYYYMMDD and YYYYMMDD HH:MM:SS formats too. It is really nice that there are unambiguous date formats in SQL Server because we have several servers with different settings. And I've met with such cases when some developers used their regional datetime formats in their queries and later had problems with that queries after running them on some other server.

    commented on Sep 7 2012 12:43AM
    Olga Medvedeva
    66 · 3% · 877
  • I use ODBC escape sequence, no need for set data format: {ts yyyy-MM-dd HH:mm:ss.fff}

    commented on Sep 7 2012 4:20AM
    Erik Ejlskov Jensen
    291 · 0% · 147
  • I think that if someone needs to run a query from some application (for example, implemented in .NET) it's better to use parameters in queries for dates (DbParameter class in ADO.NET) instead of plain text. This helps to avoid problems with date formats.

    commented on Sep 7 2012 4:44AM
    Olga Medvedeva
    66 · 3% · 877
  • Agreed with Olga Medvedeva. However you should express your date values in .NET in unambiguous way. Otherwise dates can be invalid/interepretted differently based on the Client system's date format. For example if the system's regional setting is set to MM/DD/YYYY and when you assign date value to a .NET variable, a date value 01/03/2012 can be ambiguous. If the user inputs it thinking of March 01, 2012 (format DD/MM/YYYY), it can be assigned there as Jan 03, 2012 until you also use tostring("YYYY/MM/DD"). Isn't it?

    commented on Sep 7 2012 5:23AM
    Madhivanan
    3 · 39% · 12472

Your Comment


Sign Up or Login to post a comment.

"Always use Unambiguous date formats in the queries" rated 5 out of 5 by 9 readers
Always use Unambiguous date formats in the queries , 5.0 out of 5 based on 9 ratings
    Copyright © Rivera Informatic Private Ltd Contact us      Privacy Policy      Terms of use      Report Abuse      Advertising      [ZULU1097]