0

I am trying to design an application that allows Support personnel to show system tray alerts between a certain time window in future on all user machines. So we have clients in multiple time-zones checking in to a central server looking for any new alerts to be displayed. The central DB has a table that stores the alert details with their start/end time and a webservice that responds to the clients by checking this table.

The challenge is that the client as well as the future trigger time on the server can be in any user-specified timezone. Based on a few threads that I read here, the best practice is to store the start/end time in UTC in the database and convert it to the client's timezone when a request comes in. That would mean converting all start/end times to client's timezone every few mins. I am worried this would be a major performance issue on the central server. Handling Daylight Savings times is also another point to consider.

Is there a smarter way to handle this? Any best practices to handle such scenarios would be really help.

Akshay
  • 50
  • 4
  • this is a bit too broad a question, and is likely to lead to a tutorial or opinion based answer in my mind. – Tanner Oct 03 '17 at 15:42

1 Answers1

0

Assuming you are using SQL, then you'd want to use DateTimeOffset as the data type. This type is capable of storing & manipulating both timezone and DST information.

Please see the accepted answer in this thread for the canonical answer to this class of issues: DateTime vs DateTimeOffset

dperish
  • 1,493
  • 16
  • 27