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:
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:
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:
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
- Microsoft Daylight Saving Time Help and Support Center: http://support.microsoft.com/gp/cp_dst.
- Microsoft Hot Topics for Daylight Saving Time Changes: http://support.microsoft.com/gp/dst_hottopics