We help IT Professionals succeed at work.

C# WCF DataMember DateTime to string

digitalpacman
on
Hi,

My problem is that WCF is that the run-time serializer converts DateTime data types to a complex Javascript data type ("\/Date(1275609600000-0700)\/")

My application handles the internationalization and timestamps on the server-side. So it is in the correct format for the user in the data object returned using the service.

I want the serializer to treat the data member as a string instead of a datetime.
I do not want to create new data objects for all my services, just because of this datetime flaw.

The data in my object is presented as: 6/3/2010 5:00:00 PM when .ToString() is invoked.
The data in the javascript object is: Thu Jun 03 2010 17:00:00 GMT-0700 (Pacific Daylight Time)

Anyone know how to resolve this?
Comment
Watch Question

It is not a flaw.  That is the way it is supposed to work.  The serializer preserves the data type of the C# code.  The difference is because they use different formats for the ToString() method.  Here are your choices:

   1. Use the JavaScript date object as is.
         1. Write a method that will format the string in the desired format (google javascript date format)
        Like this:http://blog.stevenlevithan.com/archives/date-time-format
            You could try the built in date function toLocaleString()
   2. Add a property that does the conversion on the C# side.  Something like this:
public String DateLocalString
{
	get {return this.Date.ToString();}
	set {this.Date = DateTime.Parse(value);}  //Will throw exception if datetime is not in correct format
}

Open in new window

Author

Commented:
The reason why I say it is a flaw is because I have the server side date formatted based on database configured settings.

That is not kept when tossed into the JSON serializer.

The server side date could be dd-mm-yyyy, and once its ran through the JSON serializer, that format is completely lost. It is not passed as a property, it does not exist.

So I have to do extra work to either pass the formatted date to the client and do my own conversions, or tell the JSON serializer to treat it as string, which is what would be better for me.

What I did so far is this:


DateTime MyDate;
[DataMember(Name="MyDate")
string MyDateFormatted { get { MyDate.ToString(); } } // Doing this is why I say its a flaw. I know the JSON serializer is meant for transmitting data, so for things like an API it would be ok. But I figured it could be used for UI display too, which makes this difficult.

I've discussed this with 6 other people I found who have used DateTime with the JSON serializer too, and they all had to "jump through hoops" in order to make it work the way they wanted.

Btw, localeFormat() and format() are added by the JSON serializer.

And flaws can be flaws even if its meant to be a certain way. The reasoning that decided it to work that way, can still be flawed.

Based on your post, however, I am assuming there is no way to accomplish what I was asking?
Formatting is hardly ever preserved when data is passed across boundaries.    It wasn't preserved when the date transfered from the database to c# and it is not preserved when the data is transfered from C# to JavaScript.  JSON only transfers the data.  It is the responsiblity of the client code to format it.  Just as it is the responsiblity of the client to format your numbers.  You would not want to format all of your numbers with $'s and ,'s in them on the server (that would make building totals difficult).

Here is something I found that describes why the date is formatted they way it is:
http://weblogs.asp.net/bleroy/archive/2008/01/18/dates-and-json.aspx

Author

Commented:
Sad how all of these problems would be solved if the JSON serializer allowed you to override the type it treats the data as.

Author

Commented:
So you are telling me there is no solution to the problem, right? You have to write custom code outside of the JSON serializer to handle dates, and there is absolutely no way through using the .NET framework that can handle this, yes?
yes that is how I see it.

Author

Commented:
Thanks, marking your first respone as the answer. =)

Author

Commented:
The solution I wanted to obtain was not possible, the answer provided is another path to solve the same problem. The exact way I wanted to solve the issue is not available under the .NET framework without changing the type of the WCF exposed object to string.