Whew - I've been racking my brain most of the morning on this one. Trying to prove to myself that types such as DateTime, decimal, etc. (types whose textual representation are subject to culture/local settings) are represented using a standard/universal format in web services calls (both ASMX and WCF).

I have a couple simple test services (ASMX and WCF) and clients (.NET web reference to ASMX, WCF client using svcutil generated proxies) that pass a decimal parameter, and get back a DataContract with a decimal and a DateTime.

All is well in ASMX world, but I'm getting an exception when calling the WCF service. (The added or subtracted value results in an un-representable DateTime.) Tracked it down to the DateTime member coming back - in the service code I'm setting it to DateTime.Now. When hacking around with the code, I set it to new DateTime( 2006, 4, 12 ); all is well.

Thanks to MSDN forums, it sounds like this is a known bug in the current CTP. See post below.

how to support datetime datamember or I am on a wrong way? - MSDN Forums

Update 04/13/06
Turns out this is only a problem if the server hosting the service is set to a timezone EAST of GMT. This causes the universal time formatted in the SOAP message to end with a "+n.nn" instead of a "-n.nn".

When I change the timezone on the server to something WEST of GMT, then it works, and I see this format in the SOAP message.
2006-04-13T09:57:56.6596416-01:00