1

Imagine this scenario - My javascript based web application, which allows users to buy an insurance policy, is accessed by users across the globe. In this application, accurate age calculation is of prime importance as the insurance premiums are calculated based on the age. The age should be calculated as follows -

Age = Current date (Pacific timezone) - User's Date of birth

I understand that I cannot use javascript's local Date() object to calculate user's age as this returns the local system time and in case the user's system's time is incorrect or the user is in a different timezone the age calculation won't be accurate.

I would like to know the best way to tackle this problem. Should I create a web service on my server that returns the current Pacific date?

Kindly share your inputs.

Thanks in advance!

Archit Arora
  • 2,508
  • 7
  • 43
  • 69
  • 1
    Date's are the number of milliseconds since `1 January 1970 0:00:00.000 UTC` - so, a little maths will allow you to figure it out – Jaromanda X Mar 19 '18 at 23:35
  • 3
    Should you consider the users timezone for their date of birth? nobody is going to convert their own date of birth to an arbitrary American date just because you're american and they are not – Jaromanda X Mar 19 '18 at 23:36
  • @JaromandaX - Consider this scenario. It's my birthday and I turn 26 in Australia. But in the USA, at that particular moment, my age is still 25 years and 364 days. If I use Javacsript's date object it will pick up the local system time and the age calculation wont be consistent. This is the scenario that I want to avoid from happening.I want the age calculation to be consistent irrespective of the user's geo location and/or system time. – Archit Arora Mar 19 '18 at 23:43
  • That level of precision is impossible unless you also ask for the user's birth location. – Daniel Beck Mar 19 '18 at 23:44
  • So, wouldn't you use the users timezone for both? Just because it's yesterday in America, doesn't mean I'm one day younger in Australia :p – Jaromanda X Mar 19 '18 at 23:45
  • 2
    Timezones are not considered in age calculations. Someone born in UTC-5 but living in a timezone UTC+10 doesn't have to wait until 3pm to celebrate their 16th birthday, or to meet any administrative milestone. Do you ask for the timezone for their birth date? Or the time of their birth? If not, just use dates without timezones. – RobG Mar 19 '18 at 23:49
  • This should be closed as primarily opinion based. Also see [*How to get the difference of two dates in mm-dd-hh format in Javascript*](https://stackoverflow.com/questions/35504942/how-to-get-the-difference-of-two-dates-in-mm-dd-hh-format-in-javascript). – RobG Mar 19 '18 at 23:52
  • as @DanielBeck mentioned, you can't assume the users birth time zone based on their current location or local time .. – Slai Mar 19 '18 at 23:53
  • @Ken White - This is an imaginary scenario. The issue is accurate age calculation and not insurance premiums. – Archit Arora Mar 19 '18 at 23:57
  • Do this serverside but not for the reason the answer suggests...Using the IP on the request, get the timezone using a service like `https://timezoneapi.io/developers/ip-address`...using the date provided by the user and a library like `momentjs` you could perform the following `moment().diff(moment.tz({y:1990, m:2, d:22}, 'America/New_York'), 'years')` as an example to get the user's true age. Assuming the IP is how you peg the user location instead of them simply supplying their location. – Eat at Joes Mar 20 '18 at 00:08

2 Answers2

4

It seems unlikely that timezone differences would be at all significant here, unless your insurance premiums go up hourly or daily. (And if so, I don't want your insurance. :) But if you can't trust the user's local clock -- and you can't -- you cannot do this in clientside javascript. It must be done serverside.

(This is, of course, true for any form validation -- validate on the client for the user's convenience, then again on the server to prevent user shenanigans.)

Daniel Beck
  • 20,653
  • 5
  • 38
  • 53
  • there can be differences if you're 24 (and 364 days) vs 25 for example – Jaromanda X Mar 19 '18 at 23:46
  • 1
    But (as above) that would depend on the user's birth timezone as much as their current timezone. Which is why afaik nobody bothers trying to examine things to that level of detail; per day is close enough. – Daniel Beck Mar 19 '18 at 23:51
  • Sure, I get that – Jaromanda X Mar 19 '18 at 23:53
  • How would "must be done serverside" ensure the user's timezone or even give a hint as to it? – Eat at Joes Mar 19 '18 at 23:59
  • 1
    @EatatJoes It wouldn't. (Note the bit where I said "it's unlikely that timezone differences are significant.") But it *would* ensure the user doesn't change their clock to sometime in 2017, and therefore get the special toddler insurance rate if the site trusts local `new Date()`. – Daniel Beck Mar 20 '18 at 00:00
0

You are missing a vital piece of information. The user's birthplace. All the messing around in the world with reducing the users present local time to your local time will only help to eliminate the potential discrepancy in today's date. To get an age accurate to +/- 1 day you must also consider the timezone of their place of birth. I agree with @Daniel Beck and @robG. This is an unworkable level of precision for age. If I was born in the UK in December and living in New Zealand (+13 h) and holidaying in Alaska (- 1d OR + 13h) when would I celebrate my birthday? I suggest you would consider yourself to be one year older on the anniversary of your date of birth at the place you are. Even if you remain conscious that this is not quite right. My sister and I were born 366 days apart. Yet I was born at 22:20 and she was born at 00:01 (my father checked the hospital clock with the time service). Technically 365d and 41min. Yet the difference in our birthdays always quoted as 'a year and a day'.

pHred
  • 121
  • 4