Hi Brian,

I've found a work around for you, and it's not too onerous.  You can see what happens on our server by stepping through a couple of lines of code in VS.  If you use the ToUniversalTime() function on the DateTime object you can simulate what is occuring on our service.

record[4].value = new DateTime(2004, 6, 11).ToUniversalTime();

record[4].value = new DateTime(2004, 6, 11, 12, 0, 0).ToUniversalTime();

The first line is what you would to if you take the documentation at face value.  It's just a date with the time defaulting to midnight.  If you inspect record[4].value you will see that it is 6/10/2004 or 10/6/2004 in UK format (June 10) and is 22 hundred hours (10:00 pm).  I believe that this is also what happens on our service.

In fact, if I use record[4].value = new DateTime(2004, 6, 11); for my values it serialized into the soap message as:

      <value xsi:type="xsd:dateTime">2004-06-11T00:00:00.0000000+02:00</value>

It is the +02:00 at the end that is pushing the date value into the previous day.

The second line is the same date (if we don't care about time).  This date represent 12:00 noon.  When you inspect record[4].value you will see that this is 6/11/2004 or 11/6/2004 in UK format.  It is also showing as 10:00 am.  Letting the code run through, the date on the opportunity will be 6/11/2004.

This behavior seems to be due to the way VS serializes dates in conjunction with the time zone.  I don't know of any easy way to prevent the offset from being included.  So, the way to handle the dueDateOnly type of field reliably from VS is to calculate your GMT offset and include a time portion in the value based on midnight - the offset.