March 13, 2009 at 10:49 am
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.
C# Gnu
____________________________________________________
March 13, 2009 at 10:54 am
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."
March 13, 2009 at 11:09 am
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.
C# Gnu
____________________________________________________
March 13, 2009 at 11:42 am
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
March 13, 2009 at 11:48 am
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."
March 13, 2009 at 11:50 am
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
March 13, 2009 at 11:53 am
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:
C# Gnu
____________________________________________________
March 13, 2009 at 11:55 am
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."
March 13, 2009 at 12:14 pm
Peso (6/30/2008)
E 12°55'05.25"N 56°04'39.16"
Lingongatan?
March 13, 2009 at 2:10 pm
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)
March 13, 2009 at 4:07 pm
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.
March 13, 2009 at 10:40 pm
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
March 13, 2009 at 11:39 pm
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
March 14, 2009 at 5:38 am
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
C# Gnu
____________________________________________________
March 14, 2009 at 5:51 pm
I like to use computative column with datediff to calculate the age.
Viewing 15 posts - 61 through 75 (of 95 total)
You must be logged in to reply to this topic. Login to reply