locked
Plug-In Date only returning UTC date. RRS feed

  • Question

  • Hi all

    I totally forgot about the UTC storage of dates in CRM and my Plug-In code is now busted.
    I've been using Date Only fields on my Entity and I created two records

    Rec 1. Dated 11-Feb-2009
    Rec 2. Dated 11-May-2009

    When I read these records back-in during a plug-in to calculate stats, the 11-Feb stayed as the 11-Feb, but the 11-May became the 10-May!!!

    It took a while for the penny to drop.
    Dates in May are BST (British Summer Time +1 hour) so the date is recorded in the database as 10-May-2009 23:00:00

    The question I have is how come this is not adjusted when retrieving records via the SDK Retrieve Multiple methods, and what is the correct way to ensure all dates retrieved via plug-ins or visual studio are showing the correct date.

    I was surpirsed to see the date come back as the 10-May and not the 11-May. I wonder how many others are blissfully unaware of this issue with manipulating dates via code?

    Regards

    Steve
    • Edited by lemonje Monday, May 18, 2009 9:16 AM
    Friday, May 15, 2009 3:38 PM

Answers

  • Hi a33ik

    I tried this and it made matters worse I still ended up on Sunday but with an earlier time.
    Then I discovered the problem.

    When using DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).date).ToLocalTime(); the date being passed in to the parser is already a day earlier so the LocalTime method is tainted.

    I then checked the available properties and notice that .Value returns 2009-05-10T23:00:00 (which is 1 hour less than I entered), when I tried DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).value).ToLocalTime(); I got back Monday (time 00:00:00).

    Which is exactly what it should be.

    Many thanks for putting me on the right road.

    Steve
    Monday, May 18, 2009 10:08 AM

All replies

  • I've being running additional checks and I still can't get the date back as it was entered.

    What I don't understand is the Plug-In should be running in the context of the caller, so why am I getting back dates based on UTC rather thand the actual date based upon the users context.

    All dates I entered between March and October when retrieved via the Plug-In are being returned a day earlier (well -1 hour which makes it the previous day).

    The code I'm using to read the date is:
    DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).date)

    If I try to use the Universal Time function on the date I end up with the date being another day earlier so dates entered as Monday in CRM are being returned via the Plug-In as Sunday and then Visual Studio returns this as Saturday.

    What is the correct way to handle reading and writing dates within Code Modules?

    Steve
    Monday, May 18, 2009 9:31 AM
  • Hi, Steve.

    Try to change code to DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).date).ToLocalTime();

    Truth is opened the prepared mind My blog - http://a33ik.blogspot.com
    Monday, May 18, 2009 9:39 AM
    Moderator
  • Hi a33ik

    I tried this and it made matters worse I still ended up on Sunday but with an earlier time.
    Then I discovered the problem.

    When using DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).date).ToLocalTime(); the date being passed in to the parser is already a day earlier so the LocalTime method is tainted.

    I then checked the available properties and notice that .Value returns 2009-05-10T23:00:00 (which is 1 hour less than I entered), when I tried DateTime.Parse(((CrmDate)Entity.Properties["new_WorkDate"]).value).ToLocalTime(); I got back Monday (time 00:00:00).

    Which is exactly what it should be.

    Many thanks for putting me on the right road.

    Steve
    Monday, May 18, 2009 10:08 AM