The Microsoft Dynamics CRM Blog
News and views from the Microsoft Dynamics CRM Team

Time Zones in Microsoft Dynamics CRM 4.0

Time Zones in Microsoft Dynamics CRM 4.0

  • Comments 2

What’s New

Time zone implementation has undergone a redesign for Dynamics CRM 4.0.  Time zone definitions are now stored in the database.  All known rules are  maintained, and allow users a “Dynamic TZ/DST” experience. 

Terminology

Time Zone - A geographic area that observes the same local time.

Time Zone Rule - The definition of a recurrence pattern of how local time is converted to/from Universal Coordinated Time (UTC).  This includes information about Daylight Savings Time (DST) versus Standard Time.  Time zone rules can change over time, thus a time zone can have multiple rules from a historic point of view, but can have only one rule that is current and in effect.

Time Zone Definition - The entire set of rules (past, present, and future) for a particular time zone.

Dynamic TZ/DST - The notion that time zone definitions change over time.

Implementation and User Experience

Note: The following information is simplified for informational purposes, and does not represent exact implementation in CRM.

Example, using “(GMT -8:00) Pacific Time (US & Canada)”, hereafter “Pacific Time”:

Time zone rules are stored in the CRM database as follows:

TimeZoneRule (a single rule corresponding to the definition for Pacific Time)

Attribute

Value

Description

RuleId

XYZ

Unique Id of this time zone rule

DefinitionId

555

Unique Id of time zone definition that this time zone rule belongs to

EffectiveDateTime

2007-01-01 00:00:00.000

The date and time when this rule becomes effective for this time zone

TimeZoneRuleVersionNumber

0

Time zone rule version

Bias

480

Offset from UTC, in minutes

DaylightBias

-60

Adjustment to Bias during DST portion of year

StandardMonth

11

Month of Standard transition

StandardDayOfWeek

0

Day of week of Standard transition (0-6)

StandardDay

1

Occurrence of day of week within month of Standard transition (1-5, 5 is last if there is no 5th occurrence)

StandardHour

2

Time of day of Standard transition

StandardMinute

0

StandardSecond

0

DaylightMonth

3

Month of Daylight transition

DaylightDayOfWeek

0

Day of week of Daylight transition (0-6)

DaylightDay

2

Occurrence of day of week within month of Daylight transition (1-5, 5 is last if there is no 5th occurrence)

DaylightHour

2

Time of day of Daylight transition

DaylightMinute

0

DaylightSecond

0

In plain English, this rule can be interpreted as:  Starting 1/1/2007, Pacific Time is 8 hours behind UTC from 2:00 a.m. on the first Sunday of November until 1:59:59 a.m. on the second Sunday in March, and is 7 hours behind UTC from 2:00 a.m. on the second Sunday in March until 1:59:59 a.m. on the first Sunday of November.

The table above shows the current rule for Pacific Time, but actually there are two rules:

RuleId

DefinitionId

EffectiveDateTime

TimeZoneRuleVersionNumber

Etc.

ABC

555

1900-01-01 00:00:00.000

0

XYZ

555

2007-01-01 00:00:00.000

0

This is interpreted as:

  • For dates between 1/1/1900 and 12/31/2006, rule ABC will be used (DST first Sun Apr– last Sun Oct)
  • For dates greater than or equal to 1/1/2007, rule XYZ will be used (DST second Sun Mar – first Sun Nov)

Let’s say a user in Pacific Time creates the following appointments:

clip_image001

Now suppose the US government decides that starting in 2009, Pacific Time will no longer observe DST.  A new rule can be added via a hotfix:

RuleId

DefinitionId

EffectiveDateTime

TimeZoneRuleVersionNumber

Etc.

ABC

555

1900-01-01 00:00:00.000

0

XYZ

555

2007-01-01 00:00:00.000

0

DEF

555

2009-01-01 00:00:00.000

1

This is interpreted as

  • - For dates between 1/1/1900 and 12/31/2006, rule ABC will be used (DST first Sun Apr– last Sun Oct)
  • - For dates between 1/1/2007 and 12/31/2008, rule XYZ will be used (DST second Sun Mar – first Sun Nov)
  • - For dates greater than or equal to 1/1/2008, rule DEF will be used (DST not observed)

Now the appointments will appear as:

clip_image002

What happened?  Why is ApptC from 8:00 – 9:00 now? 

The time zone definition changed for all dates that occur after 1/1/2009.  Since ApptC occurs after 1/1/2009 and was created before the new time zone rule (DEF) was added, it still reflects the original rule (XYZ) that was used when this appointment was created. 

Why isn’t ApptC rebased when the new time zone rule is added?

It’s not possible for anyone but the user to know for sure what the true time of the activity is intended to be.  For example, an appointment for a conference call with attendees in multiple time zones – the user’s time zone changed, but the conference call is still occurring at the originally scheduled time in another time zone that did not change.  Only the user can know what the correct time should be.  If ApptC should appear as 9:00 – 10:00 in the user’s local time, the user will have to manually modify the appointment to correct the times.

Now the user in Pacific Time creates two new appointments:

clip_image003

The appointments are stored in the database as:

Subject

Date

StartTime

EndTime

Etc.

ApptA

6/15/2006

4:00 p.m.

5:00 p.m.

ApptB

6/15/2007

4:00 p.m.

5:00 p.m.

ApptC

6/15/2010

4:00 p.m.

5:00 p.m.

ApptD

6/16/2010

5:00 p.m.

6:00 p.m.

ApptE

6/16/2005

4:00 p.m.

5:00 p.m.

Note that although ApptD and ApptE were created at the same time, a different local-to-UTC conversion happened for each one.  That is because the latest known rule for each date was used.  Rule DEF was used for ApptD and Rule ABC was used for ApptE.  This is “Dynamic TZ/DST” in action!

Frequently Asked Questions

Now that time zone definitions are stored in the database, is a hotfix still necessary for new/changed time zones?

Yes.  Direct modification of time zone definitions is not supported.  A hotfix from the Microsoft Dynamics CRM Sustained Engineering Team is required to apply new time zone rules and definitions.

What should I do if I think I am affected by an upcoming time zone definition change?

Contact your CRM administrator or your Microsoft Dynamics Support team to inquire about hotfixes.

Additional Information

Leslie Zavisca

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 1 and 7 and type the answer here:
  • Post