This question already has answers here:
Milliseconds wrong when converting from XML to SQL Server datetime
(2 answers)
DateTime vs DateTime2 Time Range Discrepancy
(3 answers)
Closed 1 year ago.
I'm trying to convert the string to datetime, but getting an unexpected result.
Select Convert(DateTime, '2015-08-10 13:08:01.725', 121);
Result:
2015-08-10 13:08:01.727
Note that the milliseconds have changed from 725 to 727.
I'm using Microsoft SQL Server 2014 (SP3-CU2) (KB4482960) - 12.0.6214.1 (X64).
This is expected, datetime is only accurate to 1/300 of a second, and .725 can't be represented by that. As a result it's rounded to the nearest 1/300, which would be .726666666666~, and then displayed as .727 as the display layer is accurate to 3 digits.
If you want to be accurate to 1/1000 of a second, use a more precise data type. datetime2(3) seems to be what you are after:
SELECT CONVERT(datetime2(3), '2015-08-10 13:08:01.725', 121);
This is because DATETIME is rounded to increments of .000, .003, or .007 seconds
Directly from Microsoft documentation
Related
This question already has answers here:
converting Epoch timestamp to sql server(human readable format)
(2 answers)
Closed 5 years ago.
I know how to convert an epoch timestamp to a SQL server timestamp using DATEADD, but I am interested in a function that does the reverse of that.
You can do it using DATEDIFF function like below :
select DATEDIFF(s, '1970-01-01 00:00:00', '2017-11-20 23:12:02.000') as EpochTimeStamp
Output :
EpochTimeStamp
--------------
1511219522
You know already how can we get back the original date :
SELECT DATEADD(ss, 1511219522, '19700101') as OriginalDate
OriginalDate
-----------------------
2017-11-20 23:12:02.000
This question already has answers here:
Why is SQL Server losing a millisecond?
(6 answers)
Closed 5 years ago.
The following query:
select convert(datetime, '2016-06-20 7:22:52.728')
gives me:
2016-06-20 07:22:52.727
In SQL Server v12.0.4100.1.
Whatever value I put for milliseconds, the result always has 1 less millisecond.
Am I missing something or is this a bug?
It's not a bug. The resolution of datetime is such that the final digit can only be one of a few values... Rounded to increments of .000, .003, or .007 seconds.
This is documented: Microsoft documentation for datetime (Transact-SQL)
That is how datetime works in sql server. If you want that millisecond, switch to datetime2([3-7]).
datetime accuracy is to 0.00333 second.
datetime2 accuracy is to 100 nanoseconds.
Date and Time Data Types and Functions (Transact-SQL)
Similarly, if you want to get the server time with additional accuracy, you would use sysdatetime() which returns datetime2(7) instead of getdate() which returns datetime.
This question already has answers here:
How to return only the Date from a SQL Server DateTime datatype
(46 answers)
Closed 7 years ago.
I have used something like this:
select* from table where cast(CreatedDate as date) = cast(GETDATE() as DATE)
in SQL Server 2008R2 and it works perfectly. But when goes to 2005, it doesn't work because Date is not a defined system type. Can anyone let me know a way that works both 2005 and 2008R2?
The CreatedDate is default as current_timestamp and I want to get data with today's data only.
You can try this:
convert(DateTime, floor(convert(float, getdate())))
That gets rid of the time part, by converting it into the underlying float number and rounding down to the nearest integer. The integer part represents the date and the decimal part is the time, so converting the integer back to a DateTime give the same date you started with but without any time part.
You can also wrap it up as a scalar-valued function:
CREATE FUNCTION [dbo].[DateTrunc] (#date DateTime)
RETURNS DateTime
AS
BEGIN
return convert(DateTime, floor(convert(float, #date)))
END
This question already has answers here:
How can I convert a Sql Server 2008 DateTimeOffset to a DateTime
(6 answers)
Closed 7 years ago.
I just need to change the date format from datatimeoffset to datetime while pulling the data
I will quote to "RichardTheKiwi"
declare #createdon datetimeoffset
set #createdon = '2008-12-19 17:30:09.1234567 +11:00'
select CONVERT(datetime2, #createdon, 1)
--Output: 2008-12-19 06:30:09.12
select convert(datetimeoffset,CONVERT(datetime2, #createdon, 1))
--Output: 2008-12-19 06:30:09.1234567 +00:00
Converting using almost any style will cause the datetime2 value to be converted to UTC.
Also, conversion from datetime2 to datetimeoffset simply sets the offset at +00:00, per the below, so it is a quick way to convert from Datetimeoffset(offset!=0) to Datetimeoffset(+00:00)
For more information you can visit: How can I convert a Sql Server 2008 DateTimeOffset to a DateTime
This question already has answers here:
T-SQL Query Returning Items It Shouldn't Be
(5 answers)
Closed 8 years ago.
Try it for yourself, maybe it is somehow related to my environment:
The query:
SELECT CAST('20140904 23:59:59.999' AS datetime)
The result:
2014-09-05 00:00:00.000
Please explain this phenomenon.
UPDATE: Alex mentioned that datetime values are rounded to increments of .000, .003, or .007 seconds. The question is why?
datetime values are rounded to increments of .000, .003, or .007 seconds
I think you should use
SELECT CAST('20140904 23:59:59.997' AS datetime)
This returns:
2014-09-04 23:59:59.997
You can find more information here: http://msdn.microsoft.com/en-us/library/ms187819.aspx
This is the accuracy of datetime function in SQL.
You could probably use datetime2 if you are using a newer version of MSSQL as the accuracy for that is 100 nanosecs.
Datetime2: http://msdn.microsoft.com/en-us/library/bb677335.aspx
The increments are part of the API spec: See this link.
datetime values are rounded to increments of .000, .003, or .007
seconds, as shown in the following table.
I found this link which has at the end a better explanation. Quote:
Actually, SQL Server does store there the clock-ticks since midnight.
Each clock-tick is equivalent to 3.33 milliseconds. That’s also the
reason why the DATETIME datatype has an accuracy of one
three-hundredth of a second.
DATETIME is 2 x 4 bytes (date + time). The time part is stored as number of ticks since midnight. Each tick is 3.33 ms
If you need more precision, take a look at DATETIME2 type. DATETIME2 Accuracy is 100ns.