I have an Entity with the following property:

```
[ScriptIgnore]
public DateTime Date
{
    get { return new DateTime(this.Ticks); }
    set { this.Ticks = value.Ticks; }
}

```

It sets the field Ticks, which is how the DateTime is stored in the database.

The problem is, I see XML come in with a Date field formatted like this:

```
<Date>2011-04-08T12:29:00.000Z</Date>

```

Which is a perfectly fine string representation of a DateTime. And in testing, this string parses to the DateTime you would expect it to.

But the date in the system gets set to 2011-04-10 12:29, or exactly two days into the future.

This happens inconsistenly, and unpredictably. I can makes hundreds of submissions, and all of them are correct. But when the client submits them in the wee hours of the morning, a handful of them end up with dates two days into the future. This leads me to several, currently unanswerable, questions:

1. What constructor or parsing method is used when the XML is deserialized into a DateTime?
2. The client is in Central time, our server is on Eastern time,(even though all times are always converted to GMT) does this have any impact?
3. What clues does the fact that most of the errors occur in the early morning hours, but cannot be reproduced the rest of the day, give me, or is this just a strange coincidence?

**UPDATE:**

After reading the following blog post: <http://blogs.msdn.com/b/bclteam/archive/2005/03/07/387677.aspx> It appears that .net DateTime does indeed have issues with deserialization. And it does indeed use the local server time, even when it shouldn't. This doesn't explain ALL my issues, but it does lead me to the decision to stop using the DateTime type in XML services, and instead have the client submit datetimes as ticks instead. As long as .Net doesn't fail at parsing longs, we should be ok.

**UPDATE 2:**

The client was against submitting datetimes as Ticks, as each OS has a different definition of what Ticks are, (client is on Java, not sure what OS) So we decided to use strings. The client did not change their submitted XML at all, but we would be able to manually parse the string to a datetime instead of letting the deserializer do it.

I have updated the Property like so:

```
[ScriptIgnore]
public string Date
{
    get { return new DateTime(this.Ticks).ToString(); }
    set
    {
        if (string.IsNullOrEmpty(value))
        {
            this.Ticks = 0;
        }
        else
        {
                this.Ticks = DateTime.Parse(value).ToUniversalTime().Ticks;
        }
    }
}

```

And the problem still exists, at 1AM this morning the client imported approximately 20 records, and only 2 of them had the date mysteriously moved forward. After looking at the raw XML of both the successfully parsed date and those that weren't, I see no difference in the format at all.

Any help at tis point greatly appreciated.