none
Project 2010 VSTO Add-In - Baseline Date Discrepancies on Different Computers RRS feed

  • Question

  • I have a client experiencing a date problem in a VSTO add-in that I can't reproduce.  The add-in puts task projected dates from our application into Baseline Start and Finish fields in MS Project.  She has a set of dates (start: 7/6/2011 end: 7/13/2011) and after the add-in processes, it shows 7/5/2011 and 7/12/2011 like it subtracted a day off each one.  Many versions ago, this problem was because we were passing a time of 00:00:00 to Baseline Start/Finish and it was making it the day before because the start date of the working day was 8AM.  Now the add-in just passes the date with no time string.  I guess the more confusing aspect though is that it works fine for me in all versions of the add-in (2007/2010, 32-bit or 64-bit).  So is there a setting in MS Project that would cause this to behave differently for her?

    I had originally wanted to hard code the times of the dates to 8:01am for starting dates and 4:59pm for ending dates, but this is not good as the working day calendar may not always be the same.  So I decided to just cut the time off and let MS Project use its brain to figure it out.  Maybe that is where I went wrong.  Here is the C# code line for BaselineFinish:

    nt.BaselineFinish = ((DateTime)t.EndDateProjected).ToShortDateString();

    where nt is the MS Project task and  t.EndDateProjected would be 7/13/2011 00:00:00 in this situation.  It translates to 7/12/2011 for her and 7/13/2011 for me in MS Project.  Any ideas on what is going on here?  

     

    Thanks,


    Cindy


    Cindy
    Friday, July 1, 2011 8:44 PM

Answers

  • Ok, I fixed it in three steps.

     

    1.  Return the datetime from SQL Server in UTC - CONVERT(VARCHAR(26), [StartDate_Projected] , 126) + 'Z'  returns '6/15/2011T00:00:00Z'

    2.  Use the Microsoft JSON Deserializer instead of the ServiceStack deserializer.  ServiceStack was returning weird times (4:14:52pm?) instead of 5:00:00pm.

    3.  Add the UTC offset back to the date in VSTO add-in - js[0].StartDateProjected.AddHours(-1*TimeZone.CurrentTimeZone.GetUtcOffset(js[0].StartDateProjected).Hours)  This changes 6/14/2011 5:00:00pm back to 6/15/2011 00:00:00

     


    Cindy
    Friday, July 8, 2011 5:08 PM

All replies

  • Hi Cindy,

    Since you aren’t able to reproduce the error there may be a difference in your respective environments or/and the environment of your respective systems.

    On what side of the International Dateline are you, and where is she? What are your respective time zones.

    What is her System DateTime setting.

    You might write a simple application which returns her Date/time and download that app to her. Then, have her run it while you wait, have her email you the results immediately. You can compare those to yours in what amounts to virtual real time.

    This doesn’t deal with your mutual problem specifically, but you might look at the content to get some ideas about the core framework of DateTime:
    TimeZone.ToUniversalTime Method (System)
    http://msdn.microsoft.com/en-us/library/system.timezone.touniversaltime.aspx

    Please let us know whether this helps resolve the issue.

    Regards,
    Chris Jensen
    Senior Technical Support Lead

    Tuesday, July 5, 2011 6:46 PM
    Moderator
  • Chris,

     

    Thank you for your help.  She is in the US Pacific time zone and I (and the server with the dates to synchronize) am in the US Eastern time zone.

    I tried changing my test computer to be in the Pacific Time Zone and it still worked fine for me.  I stepped through the add-in code to check how the dates are translated.  The date from our system is '6/12/2011 5:04:29 am'.  I set the MS Project Task.BaselineStart = '6/12/2011' with no time, and when it is done, Task.BaselineStart reads as '6/12/2011 8:00:00am'.

    I will add some logging to the add-in so I can see what the dates and times are when she runs it.  If you have any other ideas, please let me know!

     

    Thanks,


    Cindy Siders

     

     


    Cindy
    Thursday, July 7, 2011 5:56 PM
  • Actually, I was wrong!  It did break when I switched the test computer into Pacific Time Zone.  It appears that while the JSON date string has the correct tick mark for the date in EDT, when it gets serialized on the client (in PST) the date is set back into the previous day.  In JSON, the ticks represent 6/15/2011 00:00:00 UTC but my t.StartDate (C# DateTime?) = '6/14/2011 4:14:52 pm'?  

    Apparently some magic is needed on deserialization to keep it from translating the JSON tick marks into local time.


    Cindy
    Friday, July 8, 2011 4:12 PM
  • Ok, I fixed it in three steps.

     

    1.  Return the datetime from SQL Server in UTC - CONVERT(VARCHAR(26), [StartDate_Projected] , 126) + 'Z'  returns '6/15/2011T00:00:00Z'

    2.  Use the Microsoft JSON Deserializer instead of the ServiceStack deserializer.  ServiceStack was returning weird times (4:14:52pm?) instead of 5:00:00pm.

    3.  Add the UTC offset back to the date in VSTO add-in - js[0].StartDateProjected.AddHours(-1*TimeZone.CurrentTimeZone.GetUtcOffset(js[0].StartDateProjected).Hours)  This changes 6/14/2011 5:00:00pm back to 6/15/2011 00:00:00

     


    Cindy
    Friday, July 8, 2011 5:08 PM
  • Hi Cindy,

    Thanks for sharing your post of July 8 at 5:08 pm to the effect that “OK, I fixed it in three steps.” It’s curious that nobody has dealt with this issue – in public – before.  Thanks for using the forum so well.

    Regards,
    Chris Jensen
    Senior Technical Support Lead

    Monday, July 11, 2011 9:39 PM
    Moderator