Calculating Age

  • jcrawf02 (3/13/2009)


    Richard Briggs (3/13/2009)


    Comrades,

    Around one's birthday, we can be 16 in the UK, but still 15 in the US.

    Worth mentioning as may be relevant to certain age verification web applications.

    Brigzy

    16:36 UK GMT

    sp_MSGoBackInTime strikes again. How can you possibly be 16 in the UK and 15 in the US, unless you're talking about the timezone difference?

    Yes the TimeZone difference.

  • Richard Briggs (3/13/2009)


    jcrawf02 (3/13/2009)


    Richard Briggs (3/13/2009)


    Comrades,

    Around one's birthday, we can be 16 in the UK, but still 15 in the US.

    Worth mentioning as may be relevant to certain age verification web applications.

    Brigzy

    16:36 UK GMT

    sp_MSGoBackInTime strikes again. How can you possibly be 16 in the UK and 15 in the US, unless you're talking about the timezone difference?

    Yes the TimeZone difference.

    Would that really be relevant, even to web verification apps? (Not trying to be contentious, just curious). If the user is going to be the required age in a matter of hours, does it really matter if you allow them access?

    ---------------------------------------------------------
    How best to post your question[/url]
    How to post performance problems[/url]
    Tally Table:What it is and how it replaces a loop[/url]

    "stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."

  • jcrawf02 (3/13/2009)


    Richard Briggs (3/13/2009)


    jcrawf02 (3/13/2009)


    Richard Briggs (3/13/2009)


    Comrades,

    Around one's birthday, we can be 16 in the UK, but still 15 in the US.

    Worth mentioning as may be relevant to certain age verification web applications.

    Brigzy

    16:36 UK GMT

    sp_MSGoBackInTime strikes again. How can you possibly be 16 in the UK and 15 in the US, unless you're talking about the timezone difference?

    Yes the TimeZone difference.

    Would that really be relevant, even to web verification apps? (Not trying to be contentious, just curious). If the user is going to be the required age in a matter of hours, does it really matter if you allow them access?

    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

  • Richard Briggs (3/13/2009)


    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

    Perhaps, but everyone isn't born at midnight either, so you would need to store a full timestamp of the birthdate including timezone information. I doubt any of those types of applications have that level of detail.

    Andrew

    --Andrew

  • Andrew (3/13/2009)


    Richard Briggs (3/13/2009)


    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

    Perhaps, but everyone isn't born at midnight either, so you would need to store a full timestamp of the birthdate including timezone information. I doubt any of those types of applications have that level of detail.

    Andrew

    I wasn't born yesterday . . .

    . . . gotta get up early to pull one over on me . . .

    and other assorted cliche's:D

    ---------------------------------------------------------
    How best to post your question[/url]
    How to post performance problems[/url]
    Tally Table:What it is and how it replaces a loop[/url]

    "stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."

  • Here is what I use:

    SELECT EMPLOYID, BRTHDATE,

    CASE

    WHEN DATEPART(day, BRTHDATE) > DATEPART(day, getdate()) THEN DATEDIFF(month, BRTHDATE, getdate()) - 1

    ELSE DATEDIFF(month, BRTHDATE, getdate())

    END / 12 AS [Age]

    FROM

    -Mark

  • Andrew (3/13/2009)


    Richard Briggs (3/13/2009)


    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

    Perhaps, but everyone isn't born at midnight either, so you would need to store a full timestamp of the birthdate including timezone information. I doubt any of those types of applications have that level of detail.

    Andrew

    I wouldn't store timestamp:

    Suppose AutoBirthdaySurprise.com, and received a request to send money and an 'ecard' to little Tommy in Aukland Wellington, if I was hosting in the UK and didn't account for the timezone difference little tommy wouldn't get his card or his money until after 1pm :w00t:

  • Richard Briggs (3/13/2009)


    I wouldn't store timestamp:

    Suppose AutoBirthdaySurprise.com, and received a request to send money and an 'ecard' to little Tommy in Aukland Wellington, if I was hosting in the UK and didn't account for the timezone difference little tommy wouldn't get his card or his money until after 1pm :w00t:

    How spoiled is little Tommy? You're sending him money, and he wants his 14 hours of interest?

    ---------------------------------------------------------
    How best to post your question[/url]
    How to post performance problems[/url]
    Tally Table:What it is and how it replaces a loop[/url]

    "stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."

  • Peso (6/30/2008)


    E 12°55'05.25"

    N 56°04'39.16"

    Lingongatan?

  • This method includes a form of "every 4 years" leap year support. It assumes a lifetime will rarely exceed 99 years and so foregoes making allowances for the 100 year (and beyond) leap year aberrations. In addition, this method can be easily used directly in a select statement. Of course the floating point math will not yield maximum performance. Opinions on this are greatfully solicited.

    DECLARE @Years INT

    DECLARE @DOB DATETIME

    DECLARE @Compare DATETIME

    SELECT @Years = ROUND((CONVERT(FLOAT,DATEDIFF(DAY,@DOB,@Compare)) - CONVERT(FLOAT,DATEDIFF(YEAR,@DOB,@Compare)) / CONVERT(FLOAT,4)) / CONVERT(FLOAT,365),0,3)

  • One method used by my employer is what we call the window of time. It was decided that everyone in our databases could not be older than 120 years. As such an Age Table was created with the number of days, weeks, months, years, etc. This assures that no matter what you can compute the days between using datediff then look up the age you want to use. This method assures that apples are truly compared with apples because someone that is 3652 days old is the same age as someone else 3652 days old.

  • Richard Briggs (3/13/2009)


    Andrew (3/13/2009)


    Richard Briggs (3/13/2009)


    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

    Perhaps, but everyone isn't born at midnight either, so you would need to store a full timestamp of the birthdate including timezone information. I doubt any of those types of applications have that level of detail.

    Andrew

    I wouldn't store timestamp:

    Suppose AutoBirthdaySurprise.com, and received a request to send money and an 'ecard' to little Tommy in Aukland Wellington, if I was hosting in the UK and didn't account for the timezone difference little tommy wouldn't get his card or his money until after 1pm :w00t:

    That's kind of my point. If you're going to be that picky, you have to not only store the timestamp, you also have to correctly account for the timezone difference. Otherwise, it will be off somewhere.

    Andrew

    --Andrew

  • GSquared, you're welcome. Hope that method works for you (YYYYMMDD).

    Rob

    Rob Farley
    LobsterPot Solutions & Adelaide SQL Server User Group
    Company: http://www.lobsterpot.com.au
    Blog: http://blogs.lobsterpot.com.au

  • Andrew (3/13/2009)


    Richard Briggs (3/13/2009)


    Andrew (3/13/2009)


    Richard Briggs (3/13/2009)


    I guess it depends on the application, may be relevant to birthday money transfers, birthday card emails sites etc.

    Perhaps, but everyone isn't born at midnight either, so you would need to store a full timestamp of the birthdate including timezone information. I doubt any of those types of applications have that level of detail.

    Andrew

    I wouldn't store timestamp:

    Suppose AutoBirthdaySurprise.com, and received a request to send money and an 'ecard' to little Tommy in Aukland Wellington, if I was hosting in the UK and didn't account for the timezone difference little tommy wouldn't get his card or his money until after 1pm :w00t:

    That's kind of my point. If you're going to be that picky, you have to not only store the timestamp, you also have to correctly account for the timezone difference. Otherwise, it will be off somewhere.

    Andrew

    No you wouldn't need the timestamp, just shift the calculation using available timezone lookup data like this :

    "67330048","67330559","US","UNITED STATES","TEXAS","DALLAS","32.7961","-96.8024","75201","-06:00"

    "67330560","67330815","US","UNITED STATES","MISSOURI","COLUMBIA","38.9424","-92.3145","65201","-06:00"

    "67330816","67331071","US","UNITED STATES","TEXAS","DALLAS","32.7961","-96.8024","75201","-06:00"

    "67331072","67331327","US","UNITED STATES","FLORIDA","BRADENTON","27.4649","-82.5465","34201","-05:00"

    "67331328","67331583","US","UNITED STATES","ARKANSAS","TEXARKANA","33.4765","-93.9191","71854","-06:00"

    "67331584","67331839","US","UNITED STATES","TEXAS","PLANO","33.0404","-96.7238","75023","-06:00"

    As I say, only useful for some applications, but interesting all the same.

    Brigzy

  • I like to use computative column with datediff to calculate the age.

Viewing 15 posts - 61 through 75 (of 93 total)

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