+ Start a Discussion

Another date problem?

I'm using VB.Net to create Opportunities from an in house source system. I first use the query api to see if an opportunity already exists for an account and close date. If no opportunity exists, I insert a new record for the same account and close date.

Now that the GMT+ problem has been resolved, this works fine. Re-running the code only adds new transactions in the source system.

Except for close date 12/06/2004 (June, UK format) which appears in Salesforce as 11/06/2004. Re-running the code adds another record for the wrong date. Other dates process correctly. Since close date is a date only field, I would not expect timezone to enter into things (Mid-night UK still being the previous day in US). Of the dates I've tried, 12/06 is the only ambiguous date, compared to 20/12 or 29/11.

Any thoughts?


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.



My head hurts!!!

I see what you're saying. My June date was the only test date in BST (GMT+100).

Thanks for your help, I should be able to complete the job now. (Famous last words)