Recurrence and time zone awareness
 

Greets,

If you create a recurrent event in Outlook, and then change your system's
time zone setting, two things about its occurrences change: One is that the
start and end times are adjusted to compensate for difference in bias
between previous and new time zones. The other is that the
Outlook-generated text description of the recurrence pattern on the
Inspector will now reflect the time zone in which the recurrence pattern was
originally created

Example, if you open the series or any occurrence, this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM.

becomes this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM
(GMT-08:00) Pacific Time (US & Canada).

My question is: does anyone have any idea where the time zone of origin is
stored in the item, can I get to it using MAPI? (I hunted around at length
using Outlook Spy, but didn't see anything that appeared relevant, or that
differed between items created in different time zones.)

-----------
(I wanted to present my question as early in this as possible, the rest is
just additional background use case explanation. As it ran long, I isolated
the technical core of the question and moved it to the top; the rest left
in, in case anyone wonders why I asked, and to see if anyone has encountered
and/or dealt with this problem in some other way.)


Given all of the above, one might think that the way Outlook handles changes
in time zone settings seems to be both intelligent and functional -- and in
practice it actually is, all the way up to this point.

There is just one small problem: If anything causes the recurrence pattern
to be saved (regardless of whether or not it was changed) the time zone of
origin gets reset to the current time zone, and the start and end are set to
the values in the pattern! (*)

Example: if I create the recurrence pattern above in Pacific Time, start
time 11AM, and I move to Mountain Time, the start time shown on occurrences
is adjusted to 10AM -- all good -- but if I then save the recurrence pattern
at any point after, the start time will change to 11AM, and time zone of
origin becomes Mountain Time -- definitely not good, in many if not most
situations.

This can be negative behavior if the recurrent event has no physical
location and its [virtual] attendees are in multiple time zones, e.g., a
weekly conference call. Saving the recurrence pattern introduces inaccuracy
into my calendar. More, its behavior after changing time zones leaves you
with a false sense of security, by appearing to work well, but deferring
manifestation of this problem. Immediately after changing the system time
zone a user is likely to explicitly examine time-related behavior --
initially you see Outlook doing smart things. Then at some seemingly random
point in the future, it does something pretty dumb, out of the clear blue
sky... It's like a loose razor blade in a basket full of clean clothes.

If I can't get to Outlook's native storage of the time zone of origin, I'll
have to create/maintain a user defined property. Either way my plan is to
compare the time zone of origin against the system time zone. If they are
different, I need to adjust the times in the recurrence pattern, to reflect
the bias difference between the zones.

I'll also need to do a similar fixup for recurrent events created by our
sync [with SQL-based CRM] for multiple users. As is, the displayed local
time for the event is the same for all users that receive it, even if they
are in different time zones. (Needless to say, this is a seriously
unworkable flaw.)

The difficult thing to handle would be any adjustment that caused time of
day to wrap in either direction across midnight -- the only truly rational
way would be to preserve the time zone of origin, but apparently that's not
quite in the cards.

-Mark


(*) Imagining a use case where this would be beneficial is difficult for me
at best, just as a matter of ordinary logistics. If I move hundreds of
miles away, anything in my calendar that ties explicitly to my old location
becomes trash, no fixup required. Lunch at Chili's with Jane Fridays at
noon -- cancelled. Therapy session with Dr Dingdong Wednesdays at 3PM --
cancelled. Anything that remains very likely involves other people, and has
no bindings to local-time-wherever-I-may-be.

And if I'm just traveling, and temporarily change time zones, how on earth
would it ever help me to float the effective UTC to preserve a static local
time? I don't get it. The chance of implicitly altering effective UTC of an
important event is hardly justified by whatever this behavior might save me.
The only advantages I can think of might be personal sorts of things, like
maybe jogging 6:30 AM daily; mow lawn Saturdays 10AM... do people really
enter things like that in Outlook? It's got to be the exception not the
rule.

The closest things I have to that myself are a couple of monthly events to
treat my dog with Advantage Plus, and give him his anti-heartworm med --
both, time of day unimportant.

The UI ought to prompt something like, "this event was created in another
time zone, preserve its time of day in your new location? Or adjust local
time of day, to preserve effective UTC?" And the recurrence object needs a
property to dictate this behavior.

Recurrence and time zone awareness
 

see
http://blogs.msdn.com/stephen_griffi...tructures.aspx

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Mark J. McGinty" wrote in message
...
Greets,

If you create a recurrent event in Outlook, and then change your system's
time zone setting, two things about its occurrences change: One is that
the start and end times are adjusted to compensate for difference in bias
between previous and new time zones. The other is that the
Outlook-generated text description of the recurrence pattern on the
Inspector will now reflect the time zone in which the recurrence pattern
was originally created

Example, if you open the series or any occurrence, this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM.

becomes this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM
(GMT-08:00) Pacific Time (US & Canada).

My question is: does anyone have any idea where the time zone of origin is
stored in the item, can I get to it using MAPI? (I hunted around at
length using Outlook Spy, but didn't see anything that appeared relevant,
or that differed between items created in different time zones.)

-----------
(I wanted to present my question as early in this as possible, the rest is
just additional background use case explanation. As it ran long, I
isolated the technical core of the question and moved it to the top; the
rest left in, in case anyone wonders why I asked, and to see if anyone has
encountered and/or dealt with this problem in some other way.)


Given all of the above, one might think that the way Outlook handles
changes in time zone settings seems to be both intelligent and
functional -- and in practice it actually is, all the way up to this
point.

There is just one small problem: If anything causes the recurrence pattern
to be saved (regardless of whether or not it was changed) the time zone of
origin gets reset to the current time zone, and the start and end are set
to the values in the pattern! (*)

Example: if I create the recurrence pattern above in Pacific Time, start
time 11AM, and I move to Mountain Time, the start time shown on
occurrences is adjusted to 10AM -- all good -- but if I then save the
recurrence pattern at any point after, the start time will change to 11AM,
and time zone of origin becomes Mountain Time -- definitely not good, in
many if not most situations.

This can be negative behavior if the recurrent event has no physical
location and its [virtual] attendees are in multiple time zones, e.g., a
weekly conference call. Saving the recurrence pattern introduces
inaccuracy into my calendar. More, its behavior after changing time zones
leaves you with a false sense of security, by appearing to work well, but
deferring manifestation of this problem. Immediately after changing the
system time zone a user is likely to explicitly examine time-related
behavior -- initially you see Outlook doing smart things. Then at some
seemingly random point in the future, it does something pretty dumb, out
of the clear blue sky... It's like a loose razor blade in a basket full of
clean clothes.

If I can't get to Outlook's native storage of the time zone of origin,
I'll have to create/maintain a user defined property. Either way my plan
is to compare the time zone of origin against the system time zone. If
they are different, I need to adjust the times in the recurrence pattern,
to reflect the bias difference between the zones.

I'll also need to do a similar fixup for recurrent events created by our
sync [with SQL-based CRM] for multiple users. As is, the displayed local
time for the event is the same for all users that receive it, even if they
are in different time zones. (Needless to say, this is a seriously
unworkable flaw.)

The difficult thing to handle would be any adjustment that caused time of
day to wrap in either direction across midnight -- the only truly rational
way would be to preserve the time zone of origin, but apparently that's
not quite in the cards.

-Mark


(*) Imagining a use case where this would be beneficial is difficult for
me at best, just as a matter of ordinary logistics. If I move hundreds of
miles away, anything in my calendar that ties explicitly to my old
location becomes trash, no fixup required. Lunch at Chili's with Jane
Fridays at noon -- cancelled. Therapy session with Dr Dingdong Wednesdays
at 3PM -- cancelled. Anything that remains very likely involves other
people, and has no bindings to local-time-wherever-I-may-be.

And if I'm just traveling, and temporarily change time zones, how on earth
would it ever help me to float the effective UTC to preserve a static
local time? I don't get it. The chance of implicitly altering effective
UTC of an important event is hardly justified by whatever this behavior
might save me. The only advantages I can think of might be personal sorts
of things, like maybe jogging 6:30 AM daily; mow lawn Saturdays 10AM... do
people really enter things like that in Outlook? It's got to be the
exception not the rule.

The closest things I have to that myself are a couple of monthly events to
treat my dog with Advantage Plus, and give him his anti-heartworm med --
both, time of day unimportant.

The UI ought to prompt something like, "this event was created in another
time zone, preserve its time of day in your new location? Or adjust local
time of day, to preserve effective UTC?" And the recurrence object needs
a property to dictate this behavior.

Recurrence and time zone awareness
 

"Dmitry Streblechenko" wrote in message
...
see
http://blogs.msdn.com/stephen_griffi...tructures.aspx

Awesome, that's exactly what I need, thank you very much! You da man! :-)

Thanks again,
Mark



Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Mark J. McGinty" wrote in message
...
Greets,

If you create a recurrent event in Outlook, and then change your system's
time zone setting, two things about its occurrences change: One is that
the start and end times are adjusted to compensate for difference in bias
between previous and new time zones. The other is that the
Outlook-generated text description of the recurrence pattern on the
Inspector will now reflect the time zone in which the recurrence pattern
was originally created

Example, if you open the series or any occurrence, this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM.

becomes this:

Occurs every Wednesday effective 4/26/2006 from 11:00 AM to 12:00 PM
(GMT-08:00) Pacific Time (US & Canada).

My question is: does anyone have any idea where the time zone of origin
is stored in the item, can I get to it using MAPI? (I hunted around at
length using Outlook Spy, but didn't see anything that appeared relevant,
or that differed between items created in different time zones.)

-----------
(I wanted to present my question as early in this as possible, the rest
is just additional background use case explanation. As it ran long, I
isolated the technical core of the question and moved it to the top; the
rest left in, in case anyone wonders why I asked, and to see if anyone
has encountered and/or dealt with this problem in some other way.)


Given all of the above, one might think that the way Outlook handles
changes in time zone settings seems to be both intelligent and
functional -- and in practice it actually is, all the way up to this
point.

There is just one small problem: If anything causes the recurrence
pattern to be saved (regardless of whether or not it was changed) the
time zone of origin gets reset to the current time zone, and the start
and end are set to the values in the pattern! (*)

Example: if I create the recurrence pattern above in Pacific Time, start
time 11AM, and I move to Mountain Time, the start time shown on
occurrences is adjusted to 10AM -- all good -- but if I then save the
recurrence pattern at any point after, the start time will change to
11AM, and time zone of origin becomes Mountain Time -- definitely not
good, in many if not most situations.

This can be negative behavior if the recurrent event has no physical
location and its [virtual] attendees are in multiple time zones, e.g., a
weekly conference call. Saving the recurrence pattern introduces
inaccuracy into my calendar. More, its behavior after changing time
zones leaves you with a false sense of security, by appearing to work
well, but deferring manifestation of this problem. Immediately after
changing the system time zone a user is likely to explicitly examine
time-related behavior -- initially you see Outlook doing smart things.
Then at some seemingly random point in the future, it does something
pretty dumb, out of the clear blue sky... It's like a loose razor blade
in a basket full of clean clothes.

If I can't get to Outlook's native storage of the time zone of origin,
I'll have to create/maintain a user defined property. Either way my plan
is to compare the time zone of origin against the system time zone. If
they are different, I need to adjust the times in the recurrence pattern,
to reflect the bias difference between the zones.

I'll also need to do a similar fixup for recurrent events created by our
sync [with SQL-based CRM] for multiple users. As is, the displayed local
time for the event is the same for all users that receive it, even if
they are in different time zones. (Needless to say, this is a seriously
unworkable flaw.)

The difficult thing to handle would be any adjustment that caused time of
day to wrap in either direction across midnight -- the only truly
rational way would be to preserve the time zone of origin, but apparently
that's not quite in the cards.

-Mark


(*) Imagining a use case where this would be beneficial is difficult for
me at best, just as a matter of ordinary logistics. If I move hundreds
of miles away, anything in my calendar that ties explicitly to my old
location becomes trash, no fixup required. Lunch at Chili's with Jane
Fridays at noon -- cancelled. Therapy session with Dr Dingdong
Wednesdays at 3PM -- cancelled. Anything that remains very likely
involves other people, and has no bindings to
local-time-wherever-I-may-be.

And if I'm just traveling, and temporarily change time zones, how on
earth would it ever help me to float the effective UTC to preserve a
static local time? I don't get it. The chance of implicitly altering
effective UTC of an important event is hardly justified by whatever this
behavior might save me. The only advantages I can think of might be
personal sorts of things, like maybe jogging 6:30 AM daily; mow lawn
Saturdays 10AM... do people really enter things like that in Outlook?
It's got to be the exception not the rule.

The closest things I have to that myself are a couple of monthly events
to treat my dog with Advantage Plus, and give him his anti-heartworm
med -- both, time of day unimportant.

The UI ought to prompt something like, "this event was created in another
time zone, preserve its time of day in your new location? Or adjust
local time of day, to preserve effective UTC?" And the recurrence object
needs a property to dictate this behavior.