Hi,
If I have a Server/Client application which uses WinSchedule & UltraDayView and it is operated in two different timezones..... how can I ignore the timezones???
Eg: Server Timezone = UTC +5 hours Client #1 Timezone = UTC +5 hours Client #2 Timezone = UTC +6 hours
When Client #1 makes an appointment at 8AM....it appears on Client#2 to be at 9AM. Obviously the appointments start/end time is relative to each Client computer..... but how can I stop this happening....
If they make an appointment at 8 at one location then I want it to appear at 8 at all locations REGARDLESS of timezone settings on thier computer?
Unfortunately.... unlike the "UltraWebInfo" there does not seem to be a TimezoneOffset setting.
Any ideas?
regardsAaron
I still can't believe this issue was fixed so simply... I spent a couple of days scouring the web/msdn/blogs etc for answers solutions.
I did have some question marks about whether the MS Article: http://support.microsoft.com/kb/842545 was still relevent as it says it is for .NET 1.1. However at the same time there is NO good information/articles on what the DateTimeMode Property does so it was relieving to find that this property worked for me.
Brian Fallon"]Note that I recently had to add a new property, DateMemberDeserialization, to work around an MS bug in the SoapFormatter class whereby a DateTime's status as either a local or universal time is not preserved during the serialization process. This might not affect you but if necessary, you can use this property to prevent WinSchedule from picking up the wrong DateTimeKind as it might because of this bug.
I am using Binary Serialization over TCP so as you said this won't affect me. But... from reading... this seems to be a common problem for people who are merging datasets/tables. When you merge a Typed Dataset with an untyped dataset for instance... the DateTimeKind setting in the Typed dataset takes precedence. Although this is not the bug you describe... this is just a note for those people who might read this forum later.
Thanks for your help as always Brian... really appreciate it!
RegardsAaron
That is basically what I was talking about - prevent the server from marking the dates as local. Leaving DateSerializationMode at local also sounds correct, since that will prevent us from trying to convert it. That property predates the CLR2.0 support that was added to rectify confusion over local/universal time, so we don't convert to local time as the name might suggest in the more modern context. No, I don't see anything wrong with your approach.
Note that I recently had to add a new property, DateMemberDeserialization, to work around an MS bug in the SoapFormatter class whereby a DateTime's status as either a local or universal time is not preserved during the serialization process. This might not affect you but if necessary, you can use this property to prevent WinSchedule from picking up the wrong DateTimeKind as it might because of this bug.
Hi Brian,
The solution *I THINK* was to do the following
... ... ...
For Each col As DataColumn In dt.Columns If col.DataType Is GetType(System.DateTime) Then col.DateTimeMode = DataSetDateTime.Unspecified End If Next
Each time I create a datatable on the server... run through the following code and set each datacolumn DATETIMEMODE that has a datatype of DateTime to "UNSPECIFIED"
As intellisense shows.... When using this mode 'Serialization in this mode does not cause an offset"
In the Calinfo.DataBindingsForAppointments I left the DateSerializationMode = LocalTime and it all seems to work perfectly....
Is there anything wrong with what I have done?
The general solution to this problem is to use the DateTimeKind functionality that was added with CLR2.0. Since you are pushing these DataSets out from the server, and thus have control over that data, you can make sure that all DateTime structs contained therein are marked as being expressed as universal time, i.e., the DateTimeKind is set to 'Utc'. One of the DateTime constructors takes this enumeration as a parameter, so instead of making the server data specific to a particular time zone, make it use universal time for all dates, and push the responsibility of converting those dates to local time down to the client. You would then want to use universal time for the WinSchedule date serialization as well.
Thanks for your previous post Brian.
I am having a massive problem though... :(
The Problem although it is not an exactly an Infragistics Issue... it is a very relevant problem for users of your controls (the scheduling controls)
The Problem
When you pass an object of the DataSet class to a remote Web service or to a Web service that is in a time zone that is different from the time zone of the calling application, the DateTime columns in a contained table are converted to the equivalent local time. The DateTime columns are converted because the System.Data.DataSet code adjusts to the equivalent local time according to the time zone of the remote computer. For example, if a value of 5:00 is passed from a client computer in Pacific Time to a Web service in Eastern Time, the value in the DataSet object changes to 8:00 in the receiving method of the Web service. This article describes how to work around this problem by passing the time zone information from the client application to the Web service and by adjusting the DateTime columns at the remote computer. The System.Data is the namespace that contains the DataSet class.
The Following article from Microsoft explains this in detail including a workaround. But I have READ and READ and READ this article but still don't know how to implement the workaround.
http://support.microsoft.com/default.aspx?scid=kb;en-us;842545
Unfortunately simply doing the following didn't help me :-(
Brian Fallon"]See UltraCalendarInfo.DataBindingsForAppointments.DateMembersSerializationMode
It seems to be default behaviour anyway. and doing a DateSerializationMode.SerializeDatesAsUniversalTime seemed to screw up the appointments completely.
Somewhere in your library of code... do you have an implementation of a workaround that will solve my problem?
Consider my environment as such
Database --> .NET Remoting --> {{{{{INTERNET}}}}}}} --> Client
The Dataset is created on the SERVER.... NOT on the client as the microsoft article seems to demonstrate.
Any help/advice is greatly appreciated!!!!!!!!!!!!!!!!!
Regards
Aaron