Databases
StackOverflow2013
Postsdbo
POXML Service incorrectly and unpredictably parsing DateTime field
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POXML Service incorrectly and unpredictably parsing DateTime field
    primarykey
    data
    text
    <p>I have an Entity with the following property:</p> <pre><code>[ScriptIgnore] public DateTime Date { get { return new DateTime(this.Ticks); } set { this.Ticks = value.Ticks; } } </code></pre> <p>It sets the field Ticks, which is how the DateTime is stored in the database.</p> <p>The problem is, I see XML come in with a Date field formatted like this:</p> <pre><code>&lt;Date&gt;2011-04-08T12:29:00.000Z&lt;/Date&gt; </code></pre> <p>Which is a perfectly fine string representation of a DateTime. And in testing, this string parses to the DateTime you would expect it to.</p> <p>But the date in the system gets set to 2011-04-10 12:29, or exactly two days into the future.</p> <p>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:</p> <ol> <li><p>What constructor or parsing method is used when the XML is deserialized into a DateTime?</p></li> <li><p>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?</p></li> <li><p>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?</p></li> </ol> <p><strong>UPDATE:</strong></p> <p>After reading the following blog post: <a href="http://blogs.msdn.com/b/bclteam/archive/2005/03/07/387677.aspx" rel="nofollow">http://blogs.msdn.com/b/bclteam/archive/2005/03/07/387677.aspx</a> 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.</p> <p><strong>UPDATE 2:</strong></p> <p>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.</p> <p>I have updated the Property like so:</p> <pre><code>[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; } } } </code></pre> <p>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.</p> <p>Any help at tis point greatly appreciated.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USNeil N
    1. USNeil N
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. USNeil N
      1. VTBountyStart
    2. VO
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. USrazlebe
      1. VTFavorite
    3. VO
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSounds like the time is different on some machines. I don't buy "two days".
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. USJohn Saunders
    2. CO2011-04-10 12:29 is not two days after 2011-08-25T12:29:00.000Z
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. USphoog
    3. CO@John Saunders: there have been cases where the time is off by an hour or two, but those were all attributed to the assumption of one time zone over another, or not factoring in DST. But the case in which the date gets parsed 2 days into the future is real, and should not be impacted by the current datetime of the server at all.
      singulars
      1. POXML Service incorrectly and unpredictably parsing DateTime field
      1. USNeil N
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload