Datetime precision

  • Comments posted to this topic are about the item Datetime precision

  • 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.


    My MCP Transcript (ID : 692471 Access : 109741229)

  • 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. 😛

  • 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.

  • 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.

  • 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.

  • 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?

  • 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.


    My MCP Transcript (ID : 692471 Access : 109741229)

  • 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

  • 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

  • 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!

  • 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.

  • 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:

    Tom Garth
    Vertical Solutions[/url]

    "There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers
  • I am confused !



    [font="System"]Bhavesh Patel[/font]

    http://bhaveshgpatel.wordpress.com/

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply