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

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / CRM Online 2013 daylig...
Microsoft Dynamics CRM (Archived)

CRM Online 2013 daylight savings timezone data appears to be wrong?

(0) ShareShare
ReportReport
Posted on by AK350

I am dealing with service appointments and need to handle displaying appointment times based on the appointment location's local time among other things.  I did some research on the timezone data in CRM and noticed some things that don't appear to be correct.

First issue: the start and end of daylight savings time are wrong.  For example, looking at US Eastern Standard Time (EST), currently it is in standard time so the time is GMT-500.  I need to know when DST starts and ends so I can calculate correctly, but looking at the UserSettings record for the current user (using OData service endpoint) the TimeZoneDaylightMonth is 3 and TimeZoneDaylightDay is 2, if I'm reading this right that would be March 2nd, but it should be March 8th.  We also have a purchased timezone offset and daylight start/end data set in our local database that I am comparing to.  Standard month and day values appear to be correct at November 1st.

snippet from OData query results:

  <d:TimeZoneDaylightDay m:type="Edm.Int32">2</d:TimeZoneDaylightDay> 
  <d:TimeZoneCode m:type="Edm.Int32">35</d:TimeZoneCode> 
  <d:TimeZoneStandardMonth m:type="Edm.Int32">11</d:TimeZoneStandardMonth> 
  <d:TimeZoneStandardDay m:type="Edm.Int32">1</d:TimeZoneStandardDay> 
  <d:TimeZoneDaylightMonth m:type="Edm.Int32">3</d:TimeZoneDaylightMonth>

Second issue: I went a little further and linked into the TimeZoneRule record from the UserSettings record using TimeZoneCode field.  I should note here that I do see two rule records for the timezone, one record has what appears to be standard and daylight start dates that are based on old laws in the US, and the other rule record has dates that match the UserSettings record.

If I'm correct in looking at this, won't times on date/time fields in CRM display incorrectly for a period of time, for example: from March 2nd to March 8th?  Or am I missing something here?

*This post is locked for comments

I have the same question (0)
  • AK350 Profile Picture
    AK350 on at

    UPDATE: I did a test with a service appointment and setting the start and end dates to various values between March 1st and March 8th.  With each value I saved the record and looked at the UTC value by retrieving the record using the OData service endpoint.  I determined that CRM is correctly recognizing daylight savings time starting on March 8th.  So now I wonder why I'm seeing those other values in the UserSettings and TimeZoneRule records, and more importantly, is there somewhere within CRM where I can get the CORRECT start and end dates of daylight savings time?

  • Community Member Profile Picture
    Community Member on at

    We also had the same issue where we were using those fields to determine whether to apply a DST offset to a specific date/time.  We had to modify the value in the underlying database from a 2 to an 8.

  • Verified answer
    AK350 Profile Picture
    AK350 on at

    So, I was just staring at this timezone data in CRM some more trying to figure it out and I think I just realized what the issue is.  I was expecting the values to be defined as the specific month and day (as in day of the month) when daylight savings starts.  I believe that the day value (DaylightDay or TimeZoneDaylightDay depending on what entity you're looking at) is part of the standard rule definition for Daylight Savings Time.  A day value of 2 really means the second occurrence of that day in the month, and needs to be taken along with DaylightDayOfWeek value.  For example, if the month is 3, day is 2, and day of week is 0, this would be read as the second(2) Sunday(0) in March(3).  That makes sense now that I see it, this is just the rule that can be used to calculate the actual start of DST in any given year.

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…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

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