IOS and "shifted appointments" or How Exchange stores appointment start and end time.
An example of wrong meeting created by
iPhone and iPAD with IOS 5.01 and 5.1 in Moscow (+04:00 UTC without DTS) TZ
Meeting beginning:
Meeting end:
Everything fine.
Here how TZ stamp in “user friendly”
format, which showed in client:
also seems good
Here is TZ description:
Full text:
Time Zone Definition:
bMajorVersion = 0x02 (2)
bMinorVersion = 0x01 (1)
cbHeader = 0x0020 (32)
wReserved = 0x0002 (2)
cchKeyName = 0x000D (13)
szKeyName = Europe/Moscow
cRules = 0x0001 (1)
TZRule[0x0].bMajorVersion = 0x02 (2)
TZRule[0x0].bMinorVersion = 0x01 (1)
TZRule[0x0].wReserved = 0x003E (62)
TZRule[0x0].wTZRuleFlags = 0x0002 =
TZRULE_FLAG_EFFECTIVE_TZREG
TZRule[0x0].wYear = 0x0001 (1)
TZRule[0x0].X = cb: 14 lpb:
0100000001000000000000000000
TZRule[0x0].lBias = 0xFFFFFF4C (-180)
TZRule[0x0].lStandardBias = 0x00000000 (0)
TZRule[0x0].lDaylightBias = 0x00000000 (0)
TZRule[0x0].stStandardDate.wYear = 0x0 (0)
TZRule[0x0].stStandardDate.wMonth = 0x0 (0)
TZRule[0x0].stStandardDate.wDayOfWeek = 0x0
(0)
TZRule[0x0].stStandardDate.wDay = 0x0 (0)
TZRule[0x0].stStandardDate.wHour = 0x0 (0)
TZRule[0x0].stStandardDate.wMinute = 0x0
(0)
TZRule[0x0].stStandardDate.wSecond = 0x0
(0)
TZRule[0x0].stStandardDate.wMilliseconds =
0x0 (0)
TZRule[0x0].stDaylightDate.wYear = 0x0 (0)
TZRule[0x0].stDaylightDate.wMonth = 0x0 (0)
TZRule[0x0].stDaylightDate.wDayOfWeek = 0x0
(0)
TZRule[0x0].stDaylightDate.wDay = 0x0 (0)
TZRule[0x0].stDaylightDate.wHour = 0x0 (0)
TZRule[0x0].stDaylightDate.wMinute = 0x0
(0)
TZRule[0x0].stDaylightDate.wSecond = 0x0
(0)
TZRule[0x0].stDaylightDate.wMilliseconds =
0x0 (0)
Attribute description can be founded here:
https://msdn.microsoft.com/en-us/library/ee160657(v=exchg.80).aspx
This case related with:
lBias
(4 bytes): This field specifies the time zone's
offset in minutes from UTC.
iPhone stamp it as -180 from UTC (+03:00
UTC), instead of (+04:00 UTC)
Here is same attribute from meeting created
in Outlook 2010:
Time Zone Definition:
bMajorVersion = 0x02 (2)
bMinorVersion = 0x01 (1)
cbHeader = 0x0030 (48)
wReserved = 0x0002 (2)
cchKeyName = 0x0015 (21)
szKeyName = Russian Standard Time
cRules = 0x0002 (2)
It for 2010 year, where we still have DTS in Russia:
TZRule[0x0].bMajorVersion = 0x02 (2)
TZRule[0x0].bMinorVersion = 0x01 (1)
TZRule[0x0].wReserved = 0x003E (62)
TZRule[0x0].wTZRuleFlags = 0x0000 = 0x0
TZRule[0x0].wYear = 0x07DA (2010)
TZRule[0x0].X = cb: 14 lpb:
0100000001000000000000000000
TZRule[0x0].lBias = 0xFFFFFF4C (-180)
TZRule[0x0].lStandardBias = 0x00000000 (0)
TZRule[0x0].lDaylightBias = 0xFFFFFFC4
(-60)
Here we describe when we move arrows on our clocks:
TZRule[0x0].stStandardDate.wYear = 0x0 (0)
TZRule[0x0].stStandardDate.wMonth = 0xA
(10)
TZRule[0x0].stStandardDate.wDayOfWeek = 0x0
(0)
TZRule[0x0].stStandardDate.wDay = 0x5 (5)
TZRule[0x0].stStandardDate.wHour = 0x3 (3)
TZRule[0x0].stStandardDate.wMinute = 0x0
(0)
TZRule[0x0].stStandardDate.wSecond = 0x0
(0)
TZRule[0x0].stStandardDate.wMilliseconds =
0x0 (0)
TZRule[0x0].stDaylightDate.wYear = 0x0 (0)
TZRule[0x0].stDaylightDate.wMonth = 0x3 (3)
TZRule[0x0].stDaylightDate.wDayOfWeek = 0x0
(0)
TZRule[0x0].stDaylightDate.wDay = 0x5 (5)
TZRule[0x0].stDaylightDate.wHour = 0x2 (2)
TZRule[0x0].stDaylightDate.wMinute = 0x0
(0)
TZRule[0x0].stDaylightDate.wSecond = 0x0
(0)
TZRule[0x0].stDaylightDate.wMilliseconds =
0x0 (0)
Definition for year 2011 (not perfect, because we refused DST only in
summer so first month must have it? But
for 2012 it is OKey):
TZRule[0x1].bMajorVersion = 0x02 (2)
TZRule[0x1].bMinorVersion = 0x01 (1)
TZRule[0x1].wReserved = 0x003E (62)
TZRule[0x1].wTZRuleFlags = 0x0002 =
TZRULE_FLAG_EFFECTIVE_TZREG
TZRule[0x1].wYear = 0x07DB (2011)
TZRule[0x1].X = cb: 14 lpb:
0100000001000000000000000000
TZRule[0x1].lBias = 0xFFFFFF10 (-240)
TZRule[0x1].lStandardBias = 0x00000000 (0)
TZRule[0x1].lDaylightBias = 0xFFFFFFC4
(-60)
TZRule[0x1].stStandardDate.wYear = 0x0 (0)
TZRule[0x1].stStandardDate.wMonth = 0x0 (0)
TZRule[0x1].stStandardDate.wDayOfWeek = 0x0
(0)
TZRule[0x1].stStandardDate.wDay = 0x0 (0)
TZRule[0x1].stStandardDate.wHour = 0x0 (0)
TZRule[0x1].stStandardDate.wMinute = 0x0
(0)
TZRule[0x1].stStandardDate.wSecond = 0x0
(0)
TZRule[0x1].stStandardDate.wMilliseconds =
0x0 (0)
TZRule[0x1].stDaylightDate.wYear = 0x0 (0)
TZRule[0x1].stDaylightDate.wMonth = 0x0 (0)
TZRule[0x1].stDaylightDate.wDayOfWeek = 0x0
(0)
TZRule[0x1].stDaylightDate.wDay = 0x0 (0)
TZRule[0x1].stDaylightDate.wHour = 0x0 (0)
TZRule[0x1].stDaylightDate.wMinute = 0x0
(0)
TZRule[0x1].stDaylightDate.wSecond = 0x0
(0)
TZRule[0x1].stDaylightDate.wMilliseconds =
0x0 (0)
So we can see -240 minutes from UTC instead of -180 in previous one.
Resolution:
1 Involve vendor to resolve this issue
2 Use Abu-Dhabi TZ, which is +04:00 for
years w/o DTS
Comments
- Anonymous
September 15, 2014
As already, that is mentioned in http://blogs.technet.com/b/dst2007/archive/2014/08/22/announcement-update - Anonymous
September 15, 2014
As already, that is mentioned in http://blogs.technet.com/b/dst2007/archive/2014/08/22/announcement-update - Anonymous
October 01, 2014
As already, that is mentioned in http://blogs.technet.com/b/dst2007/archive/2014/08/22/announcement-update