search

jordimontana82 / fake-xrm-easy

The testing framework for Dynamics CRM and Dynamics 365 which runs on an In-Memory context and deals with mocks or fakes for you
https://dynamicsvalue.com/get-started/overview?source=git
Other
262 stars 182 forks source link

Unable to replicate behavior of Date Only fields #458

Open vinaymenda opened 5 years ago

vinaymenda commented 5 years ago

This is related to Date and Time fields with behavior set as Date Only.

When we query such fields from Dynamics 365, we get DateTime field with Kind = Unspecified. However, when we query from FakeXrmEasy, the DateTime field has Kind = Utc.

Is there a way we can specify the behavior of the Date and Time field so that FakeXrmEasy returns the DateTime exactly the way Dynamics 365 does (i.e., the Kind property set to Unspecified).

Note: We are using late bound types.

mikewama commented 4 years ago

I'm experiencing the same issue.

Jakeace17 commented 2 years ago

Same issue with version: FakeItEasy 3.2.0 FakeXrmEasy.9 1.44.0

Although I try to avoid unit test specific code I did add this extension method to work around this issue. public static DateTime ConvertDateTimeOnlyFieldToUniversalDateTime(this DateTime str) { if (str.Kind == DateTimeKind.Unspecified) { var timeZone = TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time"); return TimeZoneInfo.ConvertTimeToUtc(str, timeZone); } return str.ToUniversalTime(); } Idea being if unknown kind was pulled from Dynamics our business can assume it is Central Standard Time and convert it to Utc and if any other kind just do normal ToUniversalTime.

BetimBeja commented 2 years ago

Hello @Jakeace17, may I suggest the following blog post I wrote regarding DateTime https://xrm.al/blog/datetime-zone That being said, I think that handling automatic date conversions in the same way that dataverse does is very difficult because other than use UTC nothing else is well documented.

Jakeace17 commented 2 years ago

Hello @Jakeace17, may I suggest the following blog post I wrote regarding DateTime https://xrm.al/blog/datetime-zone That being said, I think that handling automatic date conversions in the same way that dataverse does is very difficult because other than use UTC nothing else is well documented.

Thank you @BetimBeja for the quick reply. I agree documentation is a struggle and the fact that a Date field that is Date Only having a Kind of Unspecified is something I only now noticed despite working with Dynamics for over 5 years now. Granted we very rarely us "Date Only" and just recently started mapping that field to a field we use to drive SLA on cases where time is very important.
So my goal was to take that Unspecified kind fields value and make it UTC in a plugin (were honestly I don't trust local so I assume Central Standard Time as that is the main time zone our business operates in and likely the context under which the Unspecified field was set with). I will keep in mind the extension you referenced in this link but wonder how they determine what local is while running in plugins? I know what region our Dynamics is running in (Central) but if I remember correctly it can move to other regions for disaster recovery or when ever Microsoft deems it should so want to be ready for that.

BetimBeja commented 2 years ago

Hello @Jakeace17, may I suggest the following blog post I wrote regarding DateTime https://xrm.al/blog/datetime-zone That being said, I think that handling automatic date conversions in the same way that dataverse does is very difficult because other than use UTC nothing else is well documented.

Thank you @BetimBeja for the quick reply. I agree documentation is a struggle and the fact that a Date field that is Date Only having a Kind of Unspecified is something I only now noticed despite working with Dynamics for over 5 years now. Granted we very rarely us "Date Only" and just recently started mapping that field to a field we use to drive SLA on cases where time is very important.
So my goal was to take that Unspecified kind fields value and make it UTC in a plugin (were honestly I don't trust local so I assume Central Standard Time as that is the main time zone our business operates in and likely the context under which the Unspecified field was set with). I will keep in mind the extension you referenced in this link but wonder how they determine what local is while running in plugins? I know what region our Dynamics is running in (Central) but if I remember correctly it can move to other regions for disaster recovery or when ever Microsoft deems it should so want to be ready for that.

The problem is that in a plugin all dates are UTC (even kind unspecified) and you should calculate or convert to the user local time by maintaining the kind as Unspecified. If you make Kind Local it will be using the TimeZone of the server where the code is running. in the repository I mention in my blog post you can find the actual implementation I use. There are some automatic conversions that the system applies in the pipeline if you change a value in the context to the "wrong" Kind

jordimontana82 commented 2 years ago

@vinaymenda @Jakeace17 @BetimBeja There was an implementation by another contributor who introduced a DateTimeBehavior property to manipulate these conversions.

According to what you said, DateOnly fields should return Kind = Unespecified, however that implementation is actually returning Utc.

If this had to be addressed, I would move that implementation to apply such behavior based on metadata instead. DateOnly fields are part of the metadata of entities so it fits more naturally there to me.