I have a .NET web site that captures a C# DateTime value and stores it in database with UTC value. Upon showing that datetime value on web page, what I want is that date time UTC value to be converted to web user's local time zone properly. So web users in different time zones will see the displayed date time value with different date time results.
I have 2 following approaches. I do not know which is the best and correct one.
Approach 1: Let C# server side codes to convert the UTC DateTime value to local date time using .NET library method DateTime.ToLocalTime() and pass that converted value to client side to display without any further client side codes.
Approach 2: I do not do any time conversion using C# server side codes. Instead, I simply pass the UTC datetime value to client side and I will use some client side (javaScript or some JS library) codes to do the conversion before displaying it to web user.
Question 1: Approach 1 or Approach 2 is the best and correct one?
Question 2: The .NET library DateTime.ToLocalTime() method will convert a datetime value to local time of web user; web server's local time; OR web user's computer OS time?
Question 3: How can I test my web page with different time zones to see the best/correct approach working?
Thank you for your help.
I suggest that all date/times be stored in UTC on the server and that, in your case, you do the web client timezone conversion on the client side. I suggest the Moment library for client-side operations. If you use Moment, look at the guess() method for determining the client's current timezone.
By the way, you might want to determine the client's current timezone periodically in case 1) the user in on a mobile device and physically moves to another timezone or, 2) the user's session lasts long enough to transition from Daylight Savings Time (DST) to Standard Time (STD) or vice versa.
Now, I said "in you case" because, based on your question you don't seem to need to worry about calculating time intervals between 2 date/times. If you need to do that you also have to consider the complication of changes in a timezone from 3 sources:
Also, you might need to consider the complication of dealing with the potential for a local time corresponding to two UTC times! This can happen when a local time for a location falls within the 1 hour preceeding the date/time when that location converts from DST to STD. That 1 hour period is repeated when a 'fallback' from DST to STD time occurs and so you need to resolve which of 2 possible UTC times you want to store in your database.
If any of the above timezone complications might exist for you, consider storing a location along with the date/time since this context is required for timezone calculations. The location can be lat/lon which you would need to map to a timezone or you could keep it simple and store just the timezone. Lat/lon is sometimes more desirable since sometimes governments decide to move a location into a new timezone (but this is pretty rare).