通过

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