How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

re: How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

Ilya Haykinson — Tue, 08 Mar 2005 00:16:00 GMT

Wait a sec, so .NET 2.0 doesn't fix the problems with date time serialization during remoting?? Eek!

For example, we often want to store just _date_ values in the database. We return a dataset from the server in California to, say, a client in Florida. Florida fills out a datetime value with a date (i.e. March 7, 2005 at 12:00a), and sends the dataset back to California... where it arrives as March 6, 2005 at 9:00p).

Considering that we're using Windows GUI databinding doing manual massaging on fields is very anti-good-development-practices behavior...

What are the New DateTime Features in Whidbey [Anthony Moore]

BCLTeam's WebLog — Wed, 16 Mar 2005 01:14:00 GMT

re: How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

Anthony Moore — Sat, 19 Mar 2005 01:29:00 GMT

Whidbey does solve the problem you describe with serializing just _date_ values in a database. The Unspecified mode will turn off these conversions and whole dates will be preserved. With DataSet, you can specify whether the whole column should be in the mode.

Let me know if there are still concerns with this.

re: How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

Joe — Sat, 26 Mar 2005 11:31:00 GMT

This is ridiculous. The fact that whomever built the XML Serialization in 1.0/1.1 in the first place broke the definition of DateTime (it clear states that is meant to be akin to the decimal value of a 'money' ... currency is something you add on ... as was the intent of time zone in the case of DateTime), but now you aren't fixing it? So many elegant things in .NET and then there are these absolutely ridiculous broken nasty warts that aren't being taken away.

Most likely this is due to compatibility BUT people need to go through the excercise of 'porting' onto 2.0 to begin with ... they are making the effort to change, so just fix the damn thing and reprimand the people who wrote the XML Serialization code in the first place.

I would have considered some (if feasible) some form of compiler warning system where people could turn on a 'I'm porting code from 1.1, warn me for compatibility' and it would warn on types containing date times that are heading into the serializer .... if not the compiler than at least some form of analysis tool for goodness sake.

re: How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

Joe — Sat, 26 Mar 2005 11:39:00 GMT

Also if compatibility between 2 connected systems is required, 1 that is .NET 1.1 and the other 2.0, that support a configuration for the app (config file, or maybe flag on the xml serialization class) that would handle datetime in the same fashion as 1.1.

OR

Better is to have it so the XML format contains a version number (don't recall if it does or not) ... IF there is no version number (assuming 1.1 didn't do that ... which it should have), then remain compatible to 1.1 .... the goal is that you can change the serialization mechanics based on the version ... under the hood in libraries, use the strategy pattern as an implementation mechanic so you could swap out the mechanics based on the version.

Unfortunately this really nasty item is being perpetuated into the future. Kill it while you can PLEASE (probably too late).

re: How to Work Around Problems Serializing DateTime in XML [Anthony Moore]

Anthony Moore — Sat, 26 Mar 2005 17:28:00 GMT

I definitely agree that it is extremely unfortunate what happened with XML DateTime formats in V1.0 and V1.1. It was a big mistake. Just leaving a few "z" characters off the format strings would have saved us a whole world of pain.

It would be great if we did have a migration infrastructure like you suggest. We frequently run into agonizing correctness vs. compatability tradeoffs like this that make us ask questions about something like this. However, with Whidbey we have to stick to opt-in new featueres, the Obsolete attribute and FxCop as our versioning tools. Thanks very much for your feedback about this.

I don't agree that we are perpetuating a serious problem into the future. This will be fixed "by default" in Web Services V2.0. In XmlConvert, there there are a couple of methods that we are effectively deprecating, so warnings will tell you to use a different method that does not have this bug. In WebData you also need to opt-in to the solution, but in that case it is much better to specify the nature of DateTime for the whole column anyway.

UTC y zonas horarias con Web Services

Kamikaze Reloaded — Sat, 20 Jan 2007 00:53:58 GMT

Este post es en respuesta a este caso de Edgar. Desafortunadamente no lo pude poner como comentario en

BCL Team Blog How to Work Around Problems Serializing DateTime in XML | Paid Surveys

Fri, 29 May 2009 19:10:25 GMT

PingBack from http://paidsurveyshub.info/story.php?title=bcl-team-blog-how-to-work-around-problems-serializing-datetime-in-xml