web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics CRM (Archived)

Dynamics CRM web service - best way to deal with retrieving local time dates?

(0) ShareShare
ReportReport
Posted on by 142

It seems the CRM web service always returns date time as UTC time. I had hoped to get around this by setting the user on the service proxy to be a user with the local time at as the timezone I wanted.

However, it seems like the SDK does not adhere to the users set timezone.

Does anyone have any good methods for getting the date time back in the correct timezone of the user creating the request? Mainly to save having to get the client calling the web service to have to deal with timezone conversion.

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    tw0sh3ds Profile Picture
    5,600 on at

    Hi,

    If I understand this correctly you are using SOAP endpoint and C#? Just call ToLocalTime() on your DateTime field and it will be converted to the time of the machine which is calling (and I assume that this is user machine). If this happens in the plugin (so the local timezone will be depended on the server) you should read the following article and study SDK:

    msdn.microsoft.com/.../hh547406.aspx

    using the described requests you should be able to convert the timezones as you wish

  • deanparkr Profile Picture
    142 on at

    Thanks. I have used .ToLocalTime() in one application, however, I am a little worried that because this time conversion is pushed to the client side, at some point someone might forget to convert the time which could be awkward when people are doing updates back into CRM.

    It would be useful if on the service proxy there was a way to set the connection to use the timezone setting of the calling user, to get the date/time in the same format as what the actual CRM UI does, rather than having to rely on the client to do the conversion.

    Wonder if that might a good suggestion for CRM Ideas.

  • tw0sh3ds Profile Picture
    5,600 on at

    Hi,

    I'm not sure if I don't understand you. Service proxy is on client side, so where is the difference here? It's client who creates the proxy, so what is the difference in changing the connection (on client side) and changing the resulting DateTime to local time (also on the client)? You have to be more specific here because I don't know if you are using proper names for things. What is service proxy for you?

  • deanparkr Profile Picture
    142 on at

    I am creating the proxy like this:

    OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(OrganizationUri, HomeRealmUri, Credentials, null);

               serviceProxy.EnableProxyTypes();

               serviceProxy.CallerId = "xxx"

    I then retrieve values from CRM and in this specific example I am setting ASP.Net Web Form textbox controls with the values from CRM.

    Right now for each textbox control with a date I run it through this function:

    private static string CRMDateToLocalTime (DateTime datetime)

           {

               DateTime UTCDate = Convert.ToDateTime(datetime);

               return UTCDate.ToLocalTime().ToString();

           }

    To get the local time. This is fine, because I know that CRM is sending UTC dates.  But another developer might come along later down the line and add some more date fields but not realise that the dates coming out of CRM are UTC and in need of conversion.

    I thought it might be useful if we could so something like this:

    OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(OrganizationUri, HomeRealmUri, Credentials, null);

               serviceProxy.EnableProxyTypes();

               serviceProxy.CallerId = "xxx"

               serviceProxy.UseCallerTimezone = true;

    So that we could guarantee the output to the client.

    I know, I know... we could just educate and tell people about this in code comments etc, but its more about guaranteeing a mistake like this wont happen. We are in the UK, so half of the year is the same as UTC and the other half is not.  Thus its quite easy to make the mistake of pulling down the value from CRM and not release that when UK enters daylight saving time all the dates will be wrong.

  • Suggested answer
    tw0sh3ds Profile Picture
    5,600 on at

    Ok now it's clear for me.

    It's a problem with all the systems that new developers break it :) I guess that if we wanted to make sure nobody will break the application because of the lack of knowledge, we should stop writing software :) That's why unit test are for, so you should think of creating them and you will not have any problems with your software after some time. Again we can argue about this, because for me as a developer it's always the first thing to ask when I'm retrieving data from some system - is Date in UTC, local server time or maybe my local time? I agree that it's up to developer and there are many young DEVs who just don't think about this stuff at all, but I don't think we should make special tools to make their life easier - the core principle of programming is that you understand what you are doing. But of course that's only my opinion, you should post your idea on crmideas and maybe MS will prepare something like that in future SDK. But again - of you don't trust your Developers, you should start writing unit tests.

    As for now, I think that one approach for you (if you are generating Early-Bounds using CRmSvcUtil and I assume that you are) is to prepare a plugin for CrmSvcUtil (you have some examples of such plugin in SampleCode in SDK) that will generate different "get" accessor for all DateTime properties - it will just call "ToLocalTime" for all returned DateTimes. But again - now the developers have to know that this is local time, not UTC.

    For me, as I try to be very strict about the application design, I would have a middle layer between CRM service proxy class and your website. In this middle layer you would just expose the properties you want from CRM and you can always call "ToLocalTime" there. You can quite easily prepare a unit test if all the classes from your "middle layer" are calling "ToLocalTime" for DateTime properties. You can also use PostSharp (https://www.postsharp.net) to prepare very nicely looking attributes and put them over the properties which should be returned in localtime. 

    You can also prepare your own Service Proxy - you are now instantiating OrganizationServiceProxy, but you can wrap it up over some other object that will implement IOrganizationService and will just internally call methods from OrganizationServiceProxy (CrmServiceClient from CRM Tooling library is doing exactly that). Now you just need to override RetrieveMultiple method - call standard RetrieveMultiple from OrganizationServiceProxy and in the resulting set of entities just go through all attributes and call ToLocalTime to all attributes that are of type Date. It should not affect performance too much and you will have your solution.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans