SELECT GETDATE()
Returns: 2008-09-22 15:24:13.790
I want that date part without the time part: 2008-09-22 00:00:00.000
Returns: I want that date part without the time part: |
|||||||||||||||||||||
|
|
On SQL Server 2008 and higher, you should convert to date:
On older versions, you can do the following:
for example
gives me
Pros:
|
|||||||||||||||||||||
|
|
SQLServer 2008 now has a 'date' data type which contains only a date with no time component. Anyone using SQLServer 2008 and beyond can do the following:
|
|||||||||||||
|
|
If using SQL 2008 and above:
|
|||||||||||||||||||||
|
|
DATEADD and DATEDIFF are better than CONVERTing to varchar. Both queries have the same execution plan, but execution plans are primarly about data access strategies and do not always reveal implicit costs involved in the CPU time taken to perform all the pieces. If both queries are run against a table with millions of rows, the CPU time using DateDiff can be close to 1/3rd of the Convert CPU time! To see execution plans for queries:
Both DATEADD and DATEDIFF will execute a CONVERT_IMPLICIT. Although the CONVERT solution is simpler and easier to read for some, it is slower. There is no need to cast back to datetime (this is implicitly done by the server). There is also no real need in the DateDiff method for DateAdd afterward as the integer result will also be implicitly converted back to datetime. SELECT CONVERT(varchar, MyDate, 101) FROM DatesTable
SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, MyDate)) FROM DatesTable
Using FLOOR() as @digi suggested has performance closer to DateDiff, but is not recommended as casting the datetime data type to float and back does not always yield the original value. Remember guys: Don't believe anyone. Look at the performance statistics, and test it yourself! Be careful when you're testing your results. Selecting many rows to the client will hide the performance difference becauses it takes longer to send the rows over the network than it does to perform the calculations. So make sure that the work for all the rows is done by the server but there is no rowset sent to the client. There seems to be confusion for some people about when cache optimization affects queries. Running two queries in the same batch or in separate batches has no effect on caching. So you can either expire the cache manually or simply run the queries back and forth multiple times. Any optimization for query #2 would also affect any subsequent queries, so throw out execution #1 if you like. Here is full test script and performance results that prove DateDiff is substantially faster than converting to varchar. |
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
|
||||
|
|
|
For return in date format
The above code will work in sql server 2010 It will return like 12/12/2013 For SQL Server 2012 use the below code
|
|||||||||||||||||||||
|
|
You can use the Date and Time Manipulation in SQL Server 2000 The syntax for using the convert function is:
|
||||
|
|
|
Using FLOOR() - just cut time part.
|
|||||||||
|
|
IF you want to use CONVERT and get the same output as in the original question posed, that is, yyyy-mm-dd then use If I can get on my soapbox for a second, this kind of formatting doesn't belong in the data tier, and that's why it wasn't possible without silly high-overhead 'tricks' until SQL Server 2008 when actual datepart data types are introduced. Making such conversions in the data tier is a huge waste of overhead on your DBMS, but more importantly, the second you do something like this, you have basically created in-memory orphaned data that I assume you will then return to a program. You can't put it back in to another 3NF+ column or compare it to anything typed without reverting, so all you've done is introduced points of failure and removed relational reference. You should ALWAYS go ahead and return your dateTime data type to the calling program and in the PRESENTATION tier, make whatever adjustments are necessary. As soon as you go converting things before returning them to the caller, you are removing all hope of referential integrity from the application. This would prevent an UPDATE or DELETE operation, again, unless you do some sort of manual reversion, which again is exposing your data to human/code/gremlin error when there is no need. |
|||||||||||||||||||||
|
Edit: The first two methods are essentially the same, and out perform the convert to varchar method. |
|||||||||
|
|
||||
|
|
|
If you need result in varchar datatype you should go through
which is already mentioned above If you need result in date and time format you should go through any of the below query 1) 2) 3)
--2014-03-26 00:00:00.000 |
||||
|
|
|
I think this would work in your case:
|
||||
|
|
|
Even using the ancient MSSQL Server 7.0, the code here (courtesy of this link) allowed me to get whatever date format I was looking for at the time:
It produced this output:
|
|||
|
|
|
To obtain the result indicated, I use the following command.
I holpe it is useful. |
||||
|
|
|
Okay, Though I'm bit late :), Here is the another solution.
Result
And if you are using SQL Server 2012 and higher then you can use
|
|||||
|
|
|||||
|
|
why don't you use DATE_FORMAT( your_datetiem_column, '%d-%m-%Y' ) ? EX: you can change sequence of m,d and year by re-arranging |
|||
|
|
|
|||||||||
|
If you are using SQL Server 2012 or above versions,Use There are already multiple answers and formatting types for SQL server. But most of the methods are somewhat ambiguous and it would be difficult for you to remember the numbers for format type or functions with respect to Specific Date Format. That's why in next versions of SQL server there is better option.
Culture option is very useful, as you can specify date as per your viewers. You have to remember d (for small patterns) and D (for long patterns). 1."d" - Short date pattern.
2."D" - Long date pattern.
More examples in query.
If you want more formats, you can go to: |
||||
|
|
|
You can use following for date part and formatting the date: DATENAME => Returns a character string that represents the specified datepart of the specified date DATEADD => The DATEPART =>Returns an integer that represents the specified datepart of the specified date.
|
||||
|
|
|
Date(date&time field) and DATE_FORMAT(date&time,'%Y-%m-%d') both returns only date from date&time |
|||||
|
|
I favor the following which wasn't mentioned:
It also doesn't care about local or do a double convert -- although each 'datepart' probably does math. So it may be a little slower than the datediff method, but to me it is much more clear. Especially when I want to group by just the year and month (set the day to 1). |
||||
|
|
|
This was missing in all answers, may not be the most efficient but very easy to write and understand, no style needed, no complex date functions.
|
||||
|
|
|
You can simply use the code below to get only the date part and avoid the time part in SQL:
|
||||
|
|
|
If you are assigning the results to a column or variable, give it the DATE type, and the conversion is implicit.
|
|||
|
|
|
I know this is old, but I do not see where anyone stated it this way. From what I can tell, this is ANSI standard.
It would be good if Microsoft could also support the ANSI standard CURRENT_DATE variable. |
|||
|
|
|
||||
|
|
|
SELECT CONVERT(date, getdate()) |
|||
|
|
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?