2

I need to verify certain transactions on the server side based on some time policies set by the user. The problem I see is that all the policies are relative to user timezone. If I keep only GMT offset I would get problems if the user's timezone go to DST (Daylight Saving Time).

I need to get a timezone string on user side which I should be able to use to get current time when a new transaction arrives (e.g.: the user set a policy to approve transactions from 6pm to 9 pm and the user is in Texas. When a new transaction is created I need to verify whether it's between 6pm / 9pm in Texas).

Great thanks!

Paul Exchange
  • 2,637
  • 3
  • 26
  • 33
  • 1
    Why not store all times as UTC? Then you don't care about daylight saving, timezone offset, whatever (but are still dependant on the user's clock being accurate). – RobG Nov 05 '14 at 13:24
  • Because the policies are relative to user's time (e.g.: Sunday from 6pm to 9pm). I need to check if an event is happening inside these period or not. – Paul Exchange Nov 05 '14 at 13:27
  • Convert the user's time to UTC too. This stuff is handled very much better at the server than the client. There are libraries for detecting the user's timezone based on analysing the offset for various times of the year, however these (like all client-side programs) are reliant on the user's device being set for the timezone they are in. Otherwise, as Miroslav suggests, just use strings. – RobG Nov 05 '14 at 22:56
  • Does this answer your question? [How to get the local timezone from the system using nodejs](https://stackoverflow.com/questions/38915418/how-to-get-the-local-timezone-from-the-system-using-nodejs) – Fattie Jan 13 '21 at 13:07

3 Answers3

1

I've found the anwer. I have to use https://github.com/mde/timezone-js on server side. I'll keep times relative to client's timezone string and save user's timezone string. Then to verify the policy I'll get the actual offset of the timezone like this:

var dt = new timezoneJS.Date(2006, 9, 29, 1, 59, 'America/Los_Angeles');
dt.getTimezoneOffset(); => 420

This offset is updates with DST:

// Pre-DST-leap
var dt = new timezoneJS.Date(2006, 9, 29, 1, 59, 'America/Los_Angeles');
dt.getTimezoneOffset(); => 420
// Post-DST-leap
var dt = new timezoneJS.Date(2006, 9, 29, 2, 0, 'America/Los_Angeles');
dt.getTimezoneOffset(); => 480
Paul Exchange
  • 2,637
  • 3
  • 26
  • 33
0

I'm not a js king by any means, but recently I used moment.js in a project to compare time stamps in our database (utc) to the time in our webportal (est, for me). It can be used to check if daylight savings time is shifted or even to convert times to utc.

You can read their documentation here: http://momentjs.com/docs/

I would suggest local, utc, difference, Is Daylight Saving Time and Is DST Shifted

The last two being the most useful for you.

I hope this helps!

Ed Smilovici
  • 194
  • 1
  • 1
  • 12
  • I've read that and it doesn't solve the problem since the verification is static. I need to know (may be though a web service) the current time of a location. – Paul Exchange Nov 05 '14 at 13:46
  • No, it's this easy fortunately: https://stackoverflow.com/a/65702580/294884 – Fattie Jan 13 '21 at 13:07
-2

Translate the time of the policy to UTC (when creating the policy). That's easy - getTime() (* 1000) returns the time in (mili)seconds in UTC. Simple compare of two timestamps (both in UTC) on server (Date.now()) will let you stay off the timezones problem.

(I think that was the main point of RobG comment - all times in UTC)

Miroslav Mocek
  • 857
  • 8
  • 4
  • I understand that but you aren't answering my question. If the policy is set on January I translate to UTC and then the transaction is triggered on July with DST and I'll have an incorrect policy because it will be related to a GMT that is relativly different because of DST. Am I clear? – Paul Exchange Nov 05 '14 at 14:32
  • Oh, I see, what you mean. You are changing the window, where is allowed to approve the transaction, in server time. It stays fixed 6-9 at the local time, no matter which DST. So in that case you have to provide info about localtime offset (Date - getTimezoneOffset()) to the server, so you can decide, if it fits the rule or not. (timezone offset is changing with DST)... or maybe you don't really need that at all - pass the time as string and check 6 – Miroslav Mocek Nov 05 '14 at 17:36
  • I mean - pass the time as string - as 'local' time string (from client to server), without converting to UTC. – Miroslav Mocek Nov 05 '14 at 23:10