M
Mark J. McGinty
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.
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.
