Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team

Hi,

Can you give me some more information about the issue you are seeing. As I understand it, you have a db, a server and a client. On the server you get a dataset from a data adapter. You then return the dataset as an operation return type to the client. Is this correct.

So, I don't think the presence of the database or the dataset itself is important. Once WCF has the datetime in memory, it is just a regular CLR datetime instance. WCF will then serailize it just like it would serialize any datetime. WCF does not truncate the timezone info when it serializes a datetime, and I think if you were to look at the body of the outgoing/incoming messages you would see this.

Most likely you just need to check the datetime kind property of the instances on the server and the client. You'll either find that they are both local or one is local and the other is universal. The simple fix is to call dateTime.ToUniversalTime() or dateTime.ToLocalTime() as needed.

Please let me know if that doesn't resolve your issue.

Thanks

http://msdn.microsoft.com/en-us/library/system.data.datasetdatetime(VS.80).aspx

Basically, I think the default DateTimeMode ( which can be edited on a datetime column in the dataset designer ) should default to a time mode that does not apply an offset on serialization. I think that is the issue, when you serialize, by default NO OFFSET should be applied. But the default datetimemode in a dataset designer is to UnspecifiedLocal, which applies an offset.

You can ( at least you should be able to ) change the default DateTimeMode in the dataset designer, and get the correct serialization behavior.

Sorry for coming back late.

For "Posted by Microsoft on 9/17/2009 at 4:59 PM
So, I don't think the presence of the database or the dataset itself is important. Once WCF has the datetime in memory, it is just a regular CLR datetime instance. WCF will then serailize it just like it would serialize any datetime. WCF does not truncate the timezone info when it serializes a datetime, and I think if you were to look at the body of the outgoing/incoming messages you would see this. "

When it's a single DataTime variable then you're correct and it's not a bit of problem. But when it's a DataTime column in a DataTable that comes from a DB server that is on a different TimeZone that's a problem because I have no control on the DataTime column within the DataTable. WCf automatically applies a time shift and I have no option to avoid it. There are some cases that you may want to turn off that feature. I totally like the feature but there has to be an option to control the behaviour.

Thanks.

Hi again!

I think I should give another example.

Assume we have a SQL Server at GMT -2 and a client at GMT +2. The SQL Server produces a DataTable within a DataSet. This DataTable contains a Colunm of type DATE. This column is popılated with a value "2009-10-11". After this DataSet is transferred over WCF, as a result of time difference, the client at GMT +2 read "2009-10-11 04:00:00".

That is the situation. Since I cannot modify the behaviour of WCF at this point, my client receives shifted Date values.

Thanks.

To be clear, this is not a WCF issue, but a serialization issue with regards to the .NET DateTime type. WCF simply takes a type and serializes it as the type tells it to. WCF certainly doesn’t change the value of the types in way. See this post from back in 2004 with regards to the Datetime serialization: http://blogs.msdn.com/brada/archive/2004/04/13/112784.aspx.

As Someguyonabox mentioned in a previous post, the creators of DataTable were aware of this DateTime serialization issue and provided the DateTimeMode property on the DataColumn type. The default for this happens to be DataSetDateTime.UnspecifiedLocal, which will create the timeshift that you see when the DateTime is serialized and then deserialized. However, you can change the DateTimeMode property to DataSetDateTime.Unspecified (See http://msdn.microsoft.com/en-us/library/system.data.datacolumn.datetimemode.aspx), and you will not see the timeshift anymore.

Of course, in order to change the DateTimeMode property value, you will need to enumerate thru the tables in your DataSet, and then thru the columns of each table, looking for columns of type DateTime and setting the DateTimeMode. You would need to do this within your WCF operation, after you’ve gotten the DataSet from the data provider. You could also create a custom WCF parameter inspector that could perform this for each parameter of type DataSet that it sees in the outgoing response.

Thank you for this clear explanation! And thank you Someguyonabox for you brillant participation too. I'll make changes to the application as you suggested.

Regards,
Zubeyir

This looks very similar to https://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

In Zubeyir's example of a SQL Server DATE column, there's an argument that this should be serialized as xs:Date without any time zone offset.

Thanks Joe. This is another way to the same problem.