ISDATE

  • Lokesh Vij

    SSChampion

    Points: 10836

    Comments posted to this topic are about the item ISDATE

    ~ Lokesh Vij


    Guidelines for quicker answers on T-SQL question[/url]
    Guidelines for answers on Performance questions

    Link to my Blog Post --> www.SQLPathy.com[/url]

    Follow me @Twitter

  • Raghavendra Mudugal

    SSChampion

    Points: 10658

    Thank you Lokesh-ji, Nice question.

    (So simple and yet it keeps us thinking..., to be honest I selected E,E and then seeing 2nd one's datatype as varchar, but the ISDATE takes nvarchar, so i thought again E,1 and possibly by thinking that it might return 1. Luck is playing a fair role with me in answering the question, but not a good practice for me like this, I need to be more consistent in my choice. 🙂 )

    ww; Raghu
    --
    The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.

  • kaspencer

    SSCarpal Tunnel

    Points: 4409

    As a matter of fact, SQL Server 2005 copes with this very well, provided that the data type is changed to DATETIME.

    It would seem that in SQL Server 2005 at least, DATETIME is perfectly acceptable as a datatype for ISDATE(), although as the datatype DATE does not exist in that version, it cannot be considered.

    All this makes me think that the SQL Server core developers might just have forgotten about the new data type so far as ISDATE() is concerned!

    Thus, on changing DATE to DATETIME, SQL Server 2005 return 1, 1. That's why I falied this question, having assumed that SQL 2008 onwards would be fine with DATE.

    Ken.

    You never know: reading my book: "All about your computer" might just tell you something you never knew!
    lulu.com/kaspencer

  • Lokesh Vij

    SSChampion

    Points: 10836

    kaspencer (8/28/2012)


    As a matter of fact, SQL Server 2005 copes with this very well, provided that the data type is changed to DATETIME.

    It would seem that in SQL Server 2005 at least, DATETIME is perfectly acceptable as a datatype for ISDATE(), although as the datatype DATE does not exist in that version, it cannot be considered.

    All this makes me think that the SQL Server core developers might just have forgotten about the new data type so far as ISDATE() is concerned!

    Thus, on changing DATE to DATETIME, SQL Server 2005 return 1, 1. That's why I falied this question, having assumed that SQL 2008 onwards would be fine with DATE.

    Ken.

    Agreed! For this reason the question states that this scenario is applicable for SS 2008 and above 🙂

    ~ Lokesh Vij


    Guidelines for quicker answers on T-SQL question[/url]
    Guidelines for answers on Performance questions

    Link to my Blog Post --> www.SQLPathy.com[/url]

    Follow me @Twitter

  • Lokesh Vij

    SSChampion

    Points: 10836

    Raghavendra Mudugal (8/27/2012)


    Thank you Lokesh-ji, Nice question.

    (So simple and yet it keeps us thinking..., to be honest I selected E,E and then seeing 2nd one's datatype as varchar, but the ISDATE takes nvarchar, so i thought again E,1 and possibly by thinking that it might return 1. Luck is playing a fair role with me in answering the question, but not a good practice for me like this, I need to be more consistent in my choice. 🙂 )

    Glad to know that you liked the question 🙂

    ~ Lokesh Vij


    Guidelines for quicker answers on T-SQL question[/url]
    Guidelines for answers on Performance questions

    Link to my Blog Post --> www.SQLPathy.com[/url]

    Follow me @Twitter

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    An interesting question - especially because the correct answer (and it is correct, as can be easily proven by running the code) is not what the documentation predicts.

    The documentation on ISDATE (linked in the answer explanation) says: "expression -- Is a character string or expression that can be converted to a character string."

    The documentation on converting (http://msdn.microsoft.com/en-us/library/ms187928.aspx) says that implicit conversions from date to character strings (char, varchar. nchar, and nvarchar) are allowed. As can also be easily verified by running the code below.

    So according to the documentation, the ISDATE should convert the date to character string, then test if it's a valid date. Just as it does, and always has done, when fed a datetime argument.

    The text of the error message indicates that this is a deliberate change of behaviour between the date data type and the old datetime data type, so my guess is that this is a documentation bug.

    EDIT: Forgot to paste in the demo code...

    -- Show that date will implicitly convert to string

    DECLARE @dt1 DATE = '20120828';

    SELECT RTRIM(@dt1);

    go

    -- Show that datetime will work in ISDATE (even on SQL 2008 and SQL 2012)

    DECLARE @dt1 DATETIME = '20120828';

    SELECT ISDATE(@dt1);

    go


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Andrew Watson-478275

    SSCarpal Tunnel

    Points: 4652

    I'm with Hugo on this one that it's a documentation bug on that page. It even states on the very first line of the BOL link provided (their emphasis) "Returns 1 if the expression is a valid date, time or datetime value"

    Interestingly though, on the Date/Time functions overview page, it does state "Determines whether a datetime or smalldatetime input expression is a valid date or time value."

    (http://msdn.microsoft.com/en-us/library/ms186724).

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    I've raised a documentation bug for this issue: https://connect.microsoft.com/SQLServer/feedback/details/759944/documentation-of-isdate-function-incorrect

    @andrew: That part is not actually incorrect, but it is (in my opinion) badly phrased. I would personally prefer to use the words "represents a valid date, time, or datetime value", or "can be converted to date, time, or datetime" to prevent this misunderstanding.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Koen Verbeeck

    SSC Guru

    Points: 258965

    Hugo Kornelis (8/28/2012)


    I've raised a documentation bug for this issue: https://connect.microsoft.com/SQLServer/feedback/details/759944/documentation-of-isdate-function-incorrect

    Voted +1.

    (and indicated I could reproduce it)

    Very interesting question, thanks.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Jan Van der Eecken

    SSCrazy Eights

    Points: 8895

    Just a question: Why would one want to pass a DATE to ISDATE()? Surely that should always return TRUE, even if it is NULL (which it doesn't if passed a NULL datetime or varchar)?

    --------------------------------------------------------------------------
    A little knowledge is a dangerous thing (Alexander Pope)
    In order for us to help you as efficiently as possible, please read this before posting (courtesy of Jeff Moden)[/url]

  • (Bob Brown)

    SSCrazy

    Points: 2705

    Great question Lokesh. And thanks to Hugo and others for additional education on the subject.

  • Ron McCullough

    SSC Guru

    Points: 63877

    Hugo Kornelis (8/28/2012)


    I've raised a documentation bug for this issue: https://connect.microsoft.com/SQLServer/feedback/details/759944/documentation-of-isdate-function-incorrect

    Hugo thanks - went and voted as a bug that I could reproduce, now I wish all would do the same.

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • Thomas Abraham

    SSChampion

    Points: 10761

    bitbucket-25253 (8/28/2012)


    Hugo Kornelis (8/28/2012)


    I've raised a documentation bug for this issue: https://connect.microsoft.com/SQLServer/feedback/details/759944/documentation-of-isdate-function-incorrect

    Hugo thanks - went and voted as a bug that I could reproduce, now I wish all would do the same.

    Thanks to OP et al. Nice question, and great followup. (And I chipped in my vote.)

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • Dana Medley

    SSCertifiable

    Points: 6764

    Thomas Abraham (8/28/2012)


    bitbucket-25253 (8/28/2012)


    Hugo Kornelis (8/28/2012)


    I've raised a documentation bug for this issue: https://connect.microsoft.com/SQLServer/feedback/details/759944/documentation-of-isdate-function-incorrect

    Hugo thanks - went and voted as a bug that I could reproduce, now I wish all would do the same.

    Thanks to OP et al. Nice question, and great followup. (And I chipped in my vote.)

    This was a great question and got my think tank churning this morning. Thanks for the follow up Hugo. I voted + 1 and that I could reproduce. 😀



    Everything is awesome!

  • Sean Lange

    SSC Guru

    Points: 286536

    Jan Van der Eecken (8/28/2012)


    Just a question: Why would one want to pass a DATE to ISDATE()? Surely that should always return TRUE, even if it is NULL (which it doesn't if passed a NULL datetime or varchar)?

    The same reason you can pass it a datetime. It should certainly NOT always return true. Why should a NULL return true as a date? The same logic applies to a date datatype as anything else. If it is NULL it is NULL. It can't be NULL and be a date.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

Viewing 15 posts - 1 through 15 (of 20 total)

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