This question already has answers here:
How to cast the DateTime to Time
(3 answers)
Closed 2 years ago.
How to convert getdate() to the format dd/mm/yyyy while keeping the datatype date and not varchar? This is what I tried
SELECT cast(CONVERT(varchar(12), GETDATE(), 103) as date)
but it is wrong.
The date datatype doesn't have a concept of a format. It's just a moment in time perhaps with a timezone attached but without any particular fixed representation. When you format it, it becomes a varchar. If you cast the varchar back to a date, it loses the format. This will be pretty much the same in any programming language that has a native date datatype (or date/datetime objects). It's not specific to SQL.
If you want a particular string representation of a date, then you want a varchar, so don't try to cast it back to a date.
This seems to be what's called an XY problem. What is wrong with CONVERT(varchar(12), GETDATE(), 103)? Yes, it's a varchar, but what's why are you unsatisfied with it being a varchar?
Related
This question already has an answer here:
SQL data error: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value
(1 answer)
Closed 6 years ago.
I want to convert a text date to system date format. How can I accomplish that?
I have the format where I want to convert it 'MM/DD/YYYY' for example, but it can change, it can be dd/mm/yyyy or yyyy/mm/dd.
EDIT
From SQL Server 2012 and later you might use the FORMAT function if you want to force a date into a formatted text: https://msdn.microsoft.com/en-us/library/hh213505.aspx
With earlier versions you might use something like this:
DECLARE #d DATETIME=GETDATE();
DECLARE #TargetFormat VARCHAR(100)='DD/MM/YYYY';
SELECT CONVERT(VARCHAR(100),#d, CASE #TargetFormat
WHEN 'MM/DD/YYYY' THEN 101
WHEN 'DD/MM/YYYY' THEN 103
--add all formats convert can undertsand
ELSE 101 END )
Previous
Look here: https://msdn.microsoft.com/en-us/library/ms187928.aspx
The third parameter in CONVERT specifies the format.
The MM/DD/YYYY was 101, dd/mm/yyyy was 103
But: You should avoid date literals as they are depending on your system's culture.
From your question I get that you are the owner of the source, so you can change this to the way you need it. I strongly advise you to use independent formats.
Look here: https://stackoverflow.com/a/34275965/5089204
Here is an example
SELECT CONVERT(DATETIME,'04/13/2016',101)
The result is of datetime datatype
How can I convert this 201402110544 to date(2014-02-11) in SQL server 2008?
You can cast as DATE data type (https://msdn.microsoft.com/en-us/library/bb630352(v=sql.100).aspx)
SELECT CAST(datetime_value AS DATE)
SELECT CAST(GETDATE() AS DATE) --> 2015-08-18
If you have a string to cast as DATE you can use:
SELECT CAST(LEFT('201402110544', 8) AS DATE)
You trim out the time part, by taking 1st 8 chars (YYYYMMDD) and will result a valid string to cast as DATE.
If this format is always the same, you can do this
DECLARE #d VARCHAR(20)='201402110544'
SELECT CAST(SUBSTRING(#d,0,9) as DATETIME)
Also have a look at The ultimate guide to the datetime datatypes which explains in detail about handling date-times
String to date conversion sure is a weakness of SQL Server. CONVERT does that, but can only deal with a number of given formats. So you must convert your string into such a format first and then convert it to date afterwards.
One such format is 120 = 'yyyy-mm-dd hh:mi:ss' which I think comes closest to yours. Another 102 = 'yyyy.mm.dd' suffices to get the date.
convert(
date,
concat(substring(datestring, 1,4), '.',
substring(datestring, 5,2), '.',
substring(datestring, 7,2)),
102)
from data;
SQL fiddle: http://www.sqlfiddle.com/#!3/9eecb7/3689
EDIT: I stand corrected. Horia is right; CAST supports 'yyyymmdd', so you can use it directly by merely cutting of the string's time part. This is more readable than my suggestion above, which makes CAST the better option in your case.
I can't make out from the documentation why SQL Server parses a text in a format other than the specified style.
Regardless of whether I provide text in the expected format:
SELECT CONVERT(DATETIME, N'20150601', 112)
or incorrect format (for style 113):
SELECT CONVERT(DATETIME, N'20150601', 113)
The results are the same: 2015-06-01 00:00:00.000 I would expect the latter to fail to convert the date (correctly).
What rules does it employ when trying to convert a VARCHAR to DATETIME? I.e. why does the latter (incorrect format style) still correctly parse the date?
EDIT: It seems I've not been clear enough. Style 113 should expect dd mon yyyy hh:mi:ss:mmm(24h) but it happily converts values in the format yyyymmdd for some reason.
Because the date is in a canonical format ie(20150101). The database engine falls over it implicitly. This is a compatibility feature.
If you swapped these around to UK or US date formats, you would receive conversion errors, because they cannot be implicitly converted.
EDIT: You could actually tell it to convert it to a pig, and it would still implicitly convert it to date time:
select convert(datetime,'20150425',99999999)
select convert(datetime,'20150425',100)
select convert(datetime,'20150425',113)
select convert(datetime,'20150425',010)
select convert(datetime,'20150425',8008135)
select convert(datetime,'20150425',000)
And proof of concept that this is a compatibility feature:
select convert(datetime2,'20150425',99999999)
Although you can still implicitly convert datetime2 objects, but the style must be in the scope of the conversion chart.
Reason why is the date N'20150601' converted to valid datetime is because of fact that literal N'20150601' is universal notation of datetime in SQL Server. That means, if you state datetime value in format N'yyyymmdd', SQL Server know that it is universal datetime format and know how to read it, in which order.
You should convert to varchar type in order to apply those formats:
SELECT CONVERT(varchar(100), CAST('20150601' as date), 113)
OK, you are converting datetime to datetime. What did you expect? In order to apply formats you should convert to varchar and you have to have date or time type as second parameter.
I was having problem in retrieving from SQL Server so I posted this [question][1]
I did not get any suitable answers. So I have changed the column datatype from datetime to varchar and now it works fine.
SELECT *
FROM test
WHERE (timeStamp BETWEEN '05-09-2013 18:23:57' AND '05-09-2013 18:23:59')
But my query if varchar datatype can play the role of datetime and in varchar we can also store the string then why sql provides datetime datatype? I know varchar occupies more space than datetime. I would like to know other reasons.
Change datatype of your column to datetime. You can do your query IF you'll use datetime instead of varchar in where clause:
select *
from test
where timeStamp between convert(datetime, '2013-09-05 18:23:57', 120) and convert(datetime, '2013-09-05 18:23:59', 120)
I'm pretty sure it would work even with implicit cast if you use ISO format of date:
select *
from test
where timeStamp between '2013-09-05 18:23:57' and '2013-09-05 18:23:59'
Here's more info about cast and convert.
Another reason apart from space is this:
Datetime has other functions like picking up the day, year, month,hours,minutes,seconds etc so that you don't have to write it for yourself. If you use varchar then it will be your responsibility to provide functions for future use. You should use split function to retrive the part of date you want.
Another is that a query on a varchar works slower when compared to Datetime when you use to conditions to compare month / day/ year
Always use proper DATETIME datatype to store date and time values. Refer this for more information
http://beyondrelational.com/modules/2/blogs/70/posts/10902/understanding-datetime-column-part-iv.aspx
I currently have a challenge of storing a DateTime value in a NVarChar field so that it's culture independent.
I've read that you can convert the value to an int by using CONVERT(int, GETDATE(), 112) which should make it culture independent but the former statement doesn't store the time.
What is the industry standard of storing a DateTime as culture independent?
EDIT
Please note that I can't use DateTime in my scenario. It must be NVarChar.
EDIT 2
Alright, found the answer to my own question.
To convert a DateTime to it's binary(8) raw format:
convert(binary(8), GETDATE())
I then store the value in a VARCHAR field as follows:
CONVERT(VARCHAR(MAX), convert(binary(8), GETDATE()), 2)
To retrieve it back from the varchar field and convert it to DateTime:
CONVERT(DateTime,CONVERT(binary(8), [TextField], 2))
As var as I'm concerned, this will store a DateTime as culture independent.
EDIT 3
It seems like user Kaf has the best solution. I will rather use format 126 to convert it to text and then back to DateTime from text.
Thanks everyone and sorry for the confusion.
If you CANNOT store date as Datetime, you can use style 126 which gives ISO8601 format (yyyy-mm-ddThh:mi:ss.mmm (no spaces)). I think it is culture independent.
Fiddle demo
select convert(nvarchar(50),getdate(),126)
Best thing is to store Date as a DateTime/Date type.
You should use DATETIME or DATETIME2 data type to store date and time values. They are stored in binary format in the database and are culture independent.
You can read more on MSDN here: http://msdn.microsoft.com/en-us/library/ms187819(v=sql.100).aspx
More on how SQL Server stores the datetime values: "It uses 8 bytes to store a datetime value—the first 4 for the date and the second 4 for the time." (from: http://sqlmag.com/sql-server/solving-datetime-mystery)
I do not get this idea to store a date in a varchar field so that it is 'culture independant'. dateTime data type is culture independant. What is culture dependent is the way date values are displayed:
MM/dd/YYYY
dd/MM/YYYY
YYYY-MM-DD
etc
But, if the display changes, the underlying value itself is still the same ... and this is why you can easily 'convert' dates from one format to another....
So, for the sake of simplicity, I do strongly advise you to switch to a culture-independant, datetime field. Otherwise any further use of this field's content (calculation, display, print out, etc) will be a real PITA ...