[office2000] Re: msoffice Digest V1 #15

  • From: "Greg Chapman" <greg@xxxxxxxxxxxxx>
  • To: <msoffice@xxxxxxxxxxxxx>
  • Date: Sat, 3 Aug 2002 04:43:48 -0500

Okay, I can handle it from that angle, too.<g> Ever since Outlook was
first introduced with Office 97 as a replacement for the Exchange Server
Client, it has had issues with time stamping. Every conceivable excuse
has been made for the product, always pointing the way away from the
fact that the program has some serious issues with RFC compliance in
very particular areas. Time stamping is amongst its sins, in general. It
is, probably, going to be a server problem because many of the servers
in use out there are also RFC challenged. After a sentence like that,
you may come away thinking I'm one of those "Anyone but Microsoft"
folks. It ain't true. I've been with them for a while now and frustrates
me endlessly to see problems like this one appear and never, ever go
away. All I can offer you there is a wish for good luck...and if you
find a solution that works, please, let us all know!

Outlook is pretty consistently inconsistent on this Time point. That's
why I referred you to the headers. Those will show you which app is
translating the RFC fields and which isn't. It can be either server or
application at this point but I'm willing to bet that, in this instance,
Netscape is the stronger tool and Outlook is being a demanding brat.
BTW, I failed to ask which version of Outlook you're using. I've not
experienced this issue since going to Outlook XP but I fought it to the
point of ignoring time altogether with previous versions. When I'd sort
mail items based on time, it wasn't uncommon for me to see messages
displayed out of sequence in mail threads that were going on between 3
or 4 people (not on a list). It caused all sorts of confusion. Still, as
you'll see if you read on, Outlook is extremely sensitive to what's
going on at the server. I normally don't recommend that an adjustment be
made to the tool that's working correctly just to humor the perversions
of the failing tool, but in Outlook's case it is almost the only way to
get the darned thing to behave. Read on, please...

Here's someone else reporting almost identical results as you from a
year and a half ago:
"From: Paul Diaguila (paul@xxxxxxxxxxxxxxxx)
Subject: Re: Problems with Recieved time in Outlook 2000 
Newsgroups: vmsnet.mail.pmdf
View this article only 
Date: 2000/01/05 
We started seeing the time problem with Outlook after the first of the
year.  No other clients have shown this behavior, so we assumed,
hopefully correctly, it was an Outlook problem.  The time on the pc and
PMDF machine were within 2-3 minutes of each other, but the received
time would be up to an hour off....  On the same pc, the user could
switch to Netscape and the message time would be correct.....

Paul Diaguila
Florida Information Resource Network
Tallahassee, Fl."

Later in the same thread, it became apparent that a mere config issue
between server and client being set for DST or not could have a nasty
impact on Outlook's displayed results:

"Message 6 in thread 
From: Virginia Metze (metze@xxxxxxxxxxxxxxxxxx)
Subject: RE: Problems with Recieved time in Outlook 2000 
Newsgroups: vmsnet.mail.pmdf
View this article only 
Date: 2000/01/05 

I discovered for the first time in checking our machines out just
after midnight on 2000 that pmdf showed mail as being sent at 11 p.m....
Turns out that I had never changed it from CDT, which it must have
gotten set to some time in the dim past, to CST...

I wonder how many such little things were discovered only because
Y2k made us look at things which appeared to be working a little more
closely than usual?

> problems with the recieved time being about 1 hour earlier than
> the mail was
> really received.

We've seen problems like these from time to time. Here's a brief

1. Make sure the server and the PC's are all set to standard time
saving time later, of course).

2. It seems to work best if the PC's are set to automatically adjust for
daylight saving time, rather than manually adjusting the time. Why, I

3. Obviously, the time on the server and PC's should be right (or close
right). Obvious, but you'd be surprised how many users don't have it set
correctly. (On our site, the users are forced to synch with our time
but only at logon. So, if a user stays logged on forever, his time will
never synch.)

Hope this isn't too obvious, and that it helps somewhat.

Larry Wahlers, Systems Specialist
Office of Information Systems
The Lutheran Church--Missouri Synod"

Now, that's not to say that Outlook CAN'T adjust the time. It's merely
to say it's not too reliable about which header field it will use to
judge the time or even how it will determine which header information to

Here's one of MS' own on the topic from the KB:
The field containing the date and the time that an e-mail message was
received may be incorrect. 
More Information
In Microsoft Outlook, one of the fields typically displayed in the
header of an e-mail message is the date and the time that the message
was received. An e-mail server stamps the date and the time that an
e-mail message is received as the message is processed. The date and the
time information is stored in a read-only Outlook field called
"PR_Delivery_Time." This field may contain incorrect information if the
e-mail server is not set to the correct date and time or if the format
of the date and time on the server is in a non-standard format. 

If the date and time are correctly set on the server, but the e-mail
that you receive displays incorrect date and time information, then the
date and time format on the server may be incompatible with Outlook. In
this case, you must look at the date and the time the message was sent
instead of the time it was received. The sent and received times
typically vary by the amount of time the sending and receiving e-mail
servers take to process a message.

To resolve this problem, ensure that the Time Zone settings for Outlook
are correct and match the Date/Time settings in the Windows Control
Panel. To set the Time Zone for Outlook, use the following steps: 
In Outlook, click the Tools menu and then click Options.
In the Options window, click Calendar Options.
In the Calendar Options window, click the Time Zone. 
Ensure that your Current Time Zone settings are correct and match the
Date/Time settings for Windows, and then click OK.
Click Apply and OK to close Options.
Close and restart Outlook.
For more information please see the following articles in the Microsoft
Knowledge Base: 
Q153590 : XFOR:Sent Time Incorrect on Incoming SMTP Messages 

Q156965 : XFOR: SMTP Header Time Conflicts with Sent Time on Message 

Q175475 : XFOR: Information Store May Incorrectly Stamp Time Zone Info 

Q153590 says "When the Microsoft Exchange client receives an SMTP
message in which the time zone in the header is in lowercase, and the
time zone in the header matches that of the client computer, the time
zone is ignored and Greenwich Mean Time (GMT) is assumed. This causes
the Sent time to be incorrect. 

Incorrect Time Stamp: 

Machine TZ is Eastern Standard Time (EST)
Header date filed is = Mon, 10 Jun 1996 14:10:45 est
Sent time in client shows - Sent: Monday, June 10, 1996 10:10 AM 

Correct Time Stamp: 

Machine TZ is Eastern Standard Time (EST)
Header date filed is = Mon, 10 Jun 1996 14:10:45 EST
Sent time in client shows - Sent: Monday, June 10, 1996 2:10 PM 
The Internet Mail Connector (IMC) does not recognize the lowercase time
zone value in the header as valid. The IMC then behaves as if the time
zone is GMT, and converts the message on that basis."

That's malarky on that Correct/Incorrect Time Stamp stuff. To be RFC
compliant, the tool needs to be able to "Handle All". That's a mark of
robust. Assuming that Upper Case matters while reading the field is a
mistake as only the Header name is specified in RFC2822.

In Q175475, MS says "Why does Microsoft Exchange handle time zone values
this way? Because that's the way RFC 822 defines time zones. According
to the RFC, the only time zones with recognized, or official, time zone
labels are the ones listed above. So Microsoft Exchange is functioning
in a way that is literally compliant with the applicable RFC. To do
otherwise would take us out of compliance." That, too, is malarky.
RFC822 was superceded by 2822 several years ago in practice and formally
in early 2001.It specifies 
"zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone" . No use of
labels for time zone are identified.

822 merely stated

 "        If included, day-of-week must be the day implied by the date

          Time zone may be indicated in several ways.  "UT" is Univer-
     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
     mitted as a reference to Universal Time.  The  military  standard
     uses  a  single  character for each zone.  "Z" is Universal Time.
     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
     letter "J" is not used.  The other remaining two forms are  taken
     from ANSI standard X3.51-1975.  One allows explicit indication of
     the amount of offset from UT; the other uses  common  3-character
     strings for indicating time zones in North America."

It gave the known examples and expressed them all in Upper Case.

The last referenced article explains a valid "gotcha". Something went
phooey in the logic for those Exchange Servers set to "The time zone
setting on the server is set to (GMT+1200) Wellington, Auckland."

Here's anudda set of examples but, I warn you, it may make your eyes
bleed. I only provide them so you can perform similar tests along the
way to help verify that any adjustments you make are having an effect:

This message came to my Outlook Inbox through MSN and is stamped as Aug
2, 2002 at 12:25 AM - 
Received: from cpimssmtpa37.msn.com ([]) by
cpimsstra06.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
         Thu, 1 Aug 2002 22:25:50 -0700
Received: from delivery.pens.microsoft.com ([]) by
cpimssmtpa37.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
         Thu, 1 Aug 2002 22:25:50 -0700
Received: from tkmsftddsq04 ([]) by
delivery.pens.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
         Thu, 1 Aug 2002 22:25:48 -0700
From: "Microsoft"
To: <wouldbe@xxxxxxx>
Subject: Insider Update for Preferred Customers
Date: Thu, 1 Aug 2002 22:24:53 -0700
Message-ID: <1ea24501c239e4$ee3dcef0$8fe8c90a@tkmsftddsq04>
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcI55O0RWIDgSCEGQ8OS2U3MVZje2Q==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-OriginalArrivalTime: 02 Aug 2002 05:25:48.0054 (UTC)

By following this through, you can see a couple nice points about MSN
server setups (can't believe I'm making a positive statement about MSN
servers). That is that all along the relay route, the local time of
receipt on the server and its UTC offset are recorded. That's strong
news that will help any mail client out in determining what time to
show. But Outlook, in this case, is reading the X-OriginalArrivalTime
field. When you look at the Received headers, you'll note that this
coincides with the originating SMTP server at
delivery.pens.microsoft.com...also note that it's that server's time,
not the time on the sender's pesonal computer. That time isn't even
shown and is, typically, incorrect anyway.<g> Also note, though, that
any header field prefaced with "X-" is a client specific field. They are
considered custom and are used outside the scope of RFC defined

But let's look at another one from my regular ISP:
Received: from turing.freelists.org [] by
  (SMTPD32-5.05) id A01FFE09010E; Sat, 03 Aug 2002 03:11:11 -0500
Received: from turing.(none) (localhost [])
        by turing.freelists.org (FreeLists Mail Multiplex) with ESMTP
        id 845869433D; Sat,  3 Aug 2002 03:04:05 -0500 (EST)
Received: with ECARTIS (v1.0.0; list msoffice); Sat, 03 Aug 2002
03:04:04 -0500 (EST)
Delivered-To: msoffice@xxxxxxxxxxxxx
Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net
        by turing.freelists.org (FreeLists Mail Multiplex) with ESMTP id
        for <msoffice@xxxxxxxxxxxxx>; Sat,  3 Aug 2002 03:04:03 -0500
Received: from jimbetz.com (adsl-63-193-192-46.dsl.snfc21.pacbell.net
        by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id
        for <msoffice@xxxxxxxxxxxxx>; Sat, 3 Aug 2002 04:11:06 -0400
Message-ID: <3D4B9012.A80FD42B@xxxxxxxxxxx>
Date: Sat, 03 Aug 2002 01:10:58 -0700
From: Jim Betz <jimbetz@xxxxxxxxxxx>
Organization: Seaview Software Solutions
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: msoffice@xxxxxxxxxxxxx
Subject: [office2000] Re: msoffice Digest V1 #15
References: <20020803070403.BC69D94625@xxxxxxxxxxxxxxxxxxxx>
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-archive-position: 29
X-ecartis-version: Ecartis v1.0.0
Sender: msoffice-bounce@xxxxxxxxxxxxx
Errors-To: msoffice-bounce@xxxxxxxxxxxxx
X-original-sender: jimbetz@xxxxxxxxxxx
Precedence: normal
Reply-To: msoffice@xxxxxxxxxxxxx
X-list: msoffice
X-RCPT-TO: <greg@xxxxxxxxxxxxx>
X-UIDL: 1064
Status: U

Outlook says to me that this message arrived at 3:11 AM local time.
Notice that there is no X-OriginalArriveTime so Outlook now goes to look
at the Received headers and sees that the first Received along the path
indicates that the time at transfer for this message is 0411 at
pacbell.net and that this server is offset from GMT by 4 hours (-0400).
Comparing that to local time for me (-0500 due to Daylight Savings
Time), Outlook sets the time to local. 

Greg Chapman
"Counting in binary is as easy as 01, 10, 11!
With thinking this clear, is coding really a good idea?"

> -----Original Message-----
> From: msoffice-bounce@xxxxxxxxxxxxx 
> [mailto:msoffice-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Betz
> Sent: Saturday, August 03, 2002 3:11 AM
> To: msoffice@xxxxxxxxxxxxx
> Subject: [office2000] Re: msoffice Digest V1 #15
>   This is not a 'mail server' thing.  It is Outlook.  When I 
> use NetScape Messenger and see the SAME message it shows the 
> received time adjusted for local time.  
>   My question is still - is there a way to set Outlook to 
> show the time in the RECEIVED column of the InBox in local 
> time instead of GMT?
> > Outlook doesn't really control that time. It does, however, 
> attempt to 
> > work with that time. For instance, here's the header 
> information for 
> > the message you sent to the group. You'll quickly see exactly what 
> > Outlook is working with when it presents the time:
> ==================================
> To Unsubscribe, set digest or vacation
> mode or view archives use the below link.

To Unsubscribe, set digest or vacation
mode or view archives use the below link.


Other related posts: