User will be asked to select a time (which will be local to his machine).
That's fine. For a scheduling app, that makes sense.
I want to convert that time into Eastern Standard Time.
The scheduler application will run based on EST.
That's not a good idea. The location of the server should be irrelevant. In particular, US Eastern Time fluctuates between EST and EDT. Basing it on EST would only take half of that into account, and basing it on ET would mean handling the fluctuations in your code.
In general, your server should be set to UTC, but the code running on the server should not care what time zone the server is set to.
Use DateTime.UtcNow
on the server to get the current UTC time. The value will be the same regardless of the server's time zone.
I will save the local time selected by user, Time Zone info of the user and the EST equivalent of the time selected by user.
Yes on the first two. For the third, you should store the UTC equivalent - not the EST equivalent.
You also need to be prepared to recalculate the UTC value if the time zone rules change before the event occurs.
I can get the TimeZone by using following fiddle ...
jstz will guess at the user's time zone - but it is just a guess. It could very well be wrong. It's great for picking the default option from a list of time zones, but it should not be used directly in a way that the user can't override.
Additionally, it returns an IANA TZDB identifier, such as America/Los_Angeles
. These do not currently work with TimeZoneInfo
on Windows. To use these, you'll need to use Noda Time in your C# code.