[quote user=”BOGHRD”]are they modifying the entered dates using the server(s) offset – or the clients? My best guess is the server. How do these functions work with dispersed server farms?[/quote]
WebScheduleInfo has a property on it that lets you set the TimeZoneOffset to use for this end user. Different end users talking to the same server may have different TZOs that tell WebScheduleInfo what TimeSpan to use when translating to / from UTC so that the server always sees UTC and the end user always sees their local time.
What you set the TZO to for a particular end user is usually tied to that user somehow (preference, field on that user's account, etc.) As with authenticating users, handling these preferences is something that's left up to the application. There is a WebSchedule sample demonstrating these functions and the effects of international scheduling and international dateline crossovers, that lets the user pick their time zone from a dropdown list of all of the world's timezones.
TimeZoneOffset persists between the user and whichever Web server in a server farm they are talking to for that particular request, so it shouldn't be affected at all by the user's session being handed-off to another server in a different geography because the user's preferred time zone is still part of that session. As long as you are setting the TimeZoneOffset property correctly for the end user's time zone, the WebScheduleInfo control created on the new server will know how to translate between UTC and local time.
[quote user=”BOGHRD”][/quote]how does the Infragistics Scheduler save local time to UTC time, and display UTC time to local time? Is it a bit of a trade secret?
The date/times are always stored in UTC, this is important because the persistence format and the format that the date/times are passed around in needs to be completely objective and unambiguous. The ServerTimeZoneOffset property I alluded to will always shift these date/times for display purposes to the end user's local time. The end user edits the values in his/her preferred local time zone, and those changes return to the server where the ServerTimeZoneOffset value shifts back these date/times to UTC for storage. Inside the DB everything is always UTC, and when shown to the end user everything is always converted to that user's local time.
[quote user=”BOGHRD”]I think I might be forced to attain the time offset using JavaScript, save the offset to a hidden field, and generate the date/time in SQL using the DATEADD SQL function?[/quote]
If your WebGrid column may be displaying StartDateTimes for the appointments of different users, and you want to display those times in the local time zone of the user who made them, then there is some truth to the approach you describe. You may need the time zone information along with each StartDateTime that appears in local time for display purposes though, to differentiate 1200 Eastern Standard Time from 1200 Central Europe Time for your WebGrid's users.