November 29, 2009 at 5:28 am
Comments posted to this topic are about the item Datetime precision
Craig Outcalt
November 30, 2009 at 3:15 am
I will personaly prefer to do something like cast(cast(getdate() as int) as datetime) to obtain de date of the day at midnight rather using datediff+dateadd functions.
November 30, 2009 at 5:52 am
The wording of this question is ambiguous - if the question is "what would you expect this query to return", then any answer you select is correct by definition, as it's what you would expect. 😛
November 30, 2009 at 6:28 am
Dude76 (11/30/2009)
I will personaly prefer to do something like cast(cast(getdate() as int) as datetime) to obtain de date of the day at midnight rather using datediff+dateadd functions.
There has been several discussions regarding this and iirc it was actually proven that the dateadd/datediff method is actually faster. Also, it doesn't use the knowledge of how datetime values are stored. If MS changes this, the dateadd/datediff method should still work as advertised.
November 30, 2009 at 6:34 am
SQLBOT (11/29/2009)
Comments posted to this topic are about the item <A HREF="/questions/Datetime+Manipulation/68075/">Datetime precision</A>
Thanks. After year and years working with sql, there always is something to learn.
November 30, 2009 at 7:07 am
While looking at the answer choices, my brain kept saying "Yesterday Midnight + 100ms"
For me, Midnight today is tonight and the SQL answer is this morning at 100ms after midnight or 100ms after the beginning of day.
November 30, 2009 at 7:14 am
I'm confused, if DateTime is only precise to 3.33 ms, why then is the answer just 1 ms off? Why not 3 ms?
November 30, 2009 at 7:21 am
Lynn Pettis (11/30/2009)
Dude76 (11/30/2009)
I will personaly prefer to do something like cast(cast(getdate() as int) as datetime) to obtain de date of the day at midnight rather using datediff+dateadd functions.There has been several discussions regarding this and iirc it was actually proven that the dateadd/datediff method is actually faster. Also, it doesn't use the knowledge of how datetime values are stored. If MS changes this, the dateadd/datediff method should still work as advertised.
Oh, faster rather cast, really ?
I didn't know that, and were sure that cast were a fast operation front of manipulating functions.
Thx for the info, i'll test if to have an idea of the difference of performance.
November 30, 2009 at 8:23 am
the dateadd is not commented out, just the note.
SQL is only precise to .0, .3, and .7ms, therefore you can't have .1 as the answer. It could only be one of those 3
November 30, 2009 at 8:37 am
jim.taylor (11/30/2009)
I'm confused, if DateTime is only precise to 3.33 ms, why then is the answer just 1 ms off? Why not 3 ms?
SQL Server rounded down to 100 ms from the 101ms that was added.
if you add 102ms it rounds up to 103 ms.
I posted this question because the inaccuracy caught me off guard a couple months ago when I kept getting unexpected results out of some code.
After suspecting sheer lunacy to be the root cause, I finally got the notion that maybe the SQL Server clock was dodgy. I wrote the query that you see in the question to test that theory and the BOL confirmed the rest.
To avoid the issue, use datetime2 which is more precise, but still has the same problem when you get down to 100 nanoseconds.
My issue was resolved by ignoring milliseconds since I didn't need to be that precise, and accuracy was more important than precision.
Thanks All!
~Craig
Craig Outcalt
November 30, 2009 at 8:38 am
jim.taylor (11/30/2009)
...if DateTime is only precise to 3.33 ms, why then is the answer just 1 ms off? Why not 3 ms?
When the SELECT output's ms aspect can be one of 100 (from 99.9) or 103 (from 103.23), 100 is closer :-).
I chose the wrong answer because I was thinking of roundoff in 3ms increments instead of in 3.33ms increments (although I should have realized that the choice should then have been between 99 and 102 :-)), so thank you to the questioner!
November 30, 2009 at 9:38 am
Based on all the comments here, I got completely lucky.
I assumed it was a trick question, and figured Midnight was one of those mystery values between today and yesterday, and that 1 millisecond was 'consumed' in the math. I'm clearly thinking way to hard about these QotDs.
December 2, 2009 at 8:38 am
peter.house (11/30/2009)
While looking at the answer choices, my brain kept saying "Yesterday Midnight + 100ms"For me, Midnight today is tonight and the SQL answer is this morning at 100ms after midnight or 100ms after the beginning of day.
The time element for midnight is 0, not 24. If it were 24 then the answer would have been 101 ms after midnight (tomorrow morning).:hehe:
December 10, 2009 at 10:22 pm
I am confused !
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply