S
Steve Nightingale
Could not get near this on this site's search facilities.
I spent some time on online Technet last week and could
find no answer to the following problem.
An Outlook 2000 user with a a mailbox on Exchange 2000 SP3
raises a meeting request to an external user which in the
end is sent via SMTP Internet. Forget the cases where the
recipient gets a real meeting request, .ics or .msg
attachment, all of which work fine. The problem applies
to all known cases where the request is received as a
plain text email; examples include Outlook 2000 personal
Internet mail using POP3 direct from ISP, and Notes client
with Notes server mailbox which is foreign to sending
organisation.
Both the sending and receiving PCs are correctly set to
GMT with daylight savings (effectively British Summer
Time, BST which is GMT + 1), both in Outlook 2000 and
Windows 2000 Pro settings, as are the Exchange servers and
intervening mail relays local to originating site. Say
the meeting is originally sent for 9am local (this summer,
i.e. BST) The received plain text message body states a
meeting time of 9am GMT, with no reference to BST or
Daylight savings, or time adjustment. Nett result, an
external director turns up to meet an internal director at
8am BST before the local director has even arrived at the
office who KNOWS he planned the meeting for 9am BST.
I understand it is Outlook that timestamps the raw
Calendar item (not Exchange)with a GMT time regardless of
timezone and daylight savings settings, but it does make
the neccessary adjustments before doing so, and the
receiving Outlook client in a different timezone will also
compensate accordingly when received in native format. It
would appear the TNEF format of the outgoing original
Outlook email has an incorrect GMT time for the plain text
version.
Or am I missing something?
I spent some time on online Technet last week and could
find no answer to the following problem.
An Outlook 2000 user with a a mailbox on Exchange 2000 SP3
raises a meeting request to an external user which in the
end is sent via SMTP Internet. Forget the cases where the
recipient gets a real meeting request, .ics or .msg
attachment, all of which work fine. The problem applies
to all known cases where the request is received as a
plain text email; examples include Outlook 2000 personal
Internet mail using POP3 direct from ISP, and Notes client
with Notes server mailbox which is foreign to sending
organisation.
Both the sending and receiving PCs are correctly set to
GMT with daylight savings (effectively British Summer
Time, BST which is GMT + 1), both in Outlook 2000 and
Windows 2000 Pro settings, as are the Exchange servers and
intervening mail relays local to originating site. Say
the meeting is originally sent for 9am local (this summer,
i.e. BST) The received plain text message body states a
meeting time of 9am GMT, with no reference to BST or
Daylight savings, or time adjustment. Nett result, an
external director turns up to meet an internal director at
8am BST before the local director has even arrived at the
office who KNOWS he planned the meeting for 9am BST.
I understand it is Outlook that timestamps the raw
Calendar item (not Exchange)with a GMT time regardless of
timezone and daylight savings settings, but it does make
the neccessary adjustments before doing so, and the
receiving Outlook client in a different timezone will also
compensate accordingly when received in native format. It
would appear the TNEF format of the outgoing original
Outlook email has an incorrect GMT time for the plain text
version.
Or am I missing something?