I register the following javascript on my web page. When the user posts back, SOMETIMES the txtTimeZoneOffSet hidden field comes back as blank. When I test on my computer, I always get a value. It happens on different browsers (I.E, FireFox, and Safari).
I am trying to get the users offset, so when they enter a date, I can convert it to UTC on the server and deal with everything in the same timezone, then when I render dates back out to them, I make sure it is in their timezone.
<script type='text/javascript'>
$(window).load(function () {
var d = new Date();
var tz = d.getTimezoneOffset();
$('#txtTimeZoneOffSet').val(tz / 60);
});
</script>
Does anyone see why this would not work 100% of the time?
The jQuery looks fine to me, so I don't see why it wouldn't work unless JavaScript was disabled or you didn't load jQuery.
However, you are worked on a flawed assumption that the user's current offset will be the same for all dates. In any time zone that has daylight saving time, it could be wrong.
The better approach would be to convert to UTC on the browser. Or at least use the date/time in question in the call to getTimezoneOffset.
UPDATED ANSWER
In response to your question, the code you have now will get the current offset already. You are just not guaranteed that it will be the same offset for any date they might enter. For example:
<input type="text" id="someDate" />
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var offset = dt.getTimezoneOffset();
Since the value of the text input is variable, in many time zones you will get a different offset for January than you will for June. So the better thing would be to just convert it to UTC on the browser:
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var s = dt.toISOString();
The string s will be in ISO8601 format, and will already be converted to UTC.
Of course, if it were me I would do this using moment.js - since it gives you much better control of how the input string is parsed.
This approach is usually good enough. HOWEVER, if there is any chance you will have to do this conversion on the server, perhaps because the user is not present, then you must know their time zone. Not just the offset, but the actual time zone. See "Time Zone != Offset" in the timezone tag wiki.
The best way is to ask them for it. A map-based picker like this one is a nice touch. You can even guess at a default selection using jsTimezoneDetect. Ultimately you are after a string identifier like America/New_York that you can use on your server. In .Net you can use these with the TZDB provider in Noda Time.
If you don't want any fancy libraries, you can stick with Windows time zones, and present a dropdown list from TimeZoneInfo.GetSystemTimeZones(), where the .Id is the key and the .DisplayName is the value.