OpenVMS V7.3-2 (Update V1, SYS V2, PCSI V1, Manage V1, DCL V1) with
TCPIP V5.4 and DECnet Phase IV (so no DTSS) on a DS15.  This system
was installed in late March and has been running well. 
SYS$MANAGER:UTC$TIME_SETUP.COM was run upon configuration.  This alpha
is (among other things) the central mail server for a small business,
with clients on PCs running outhouse express (stock versions with
Win2K and WinXP, but updated as security requires).  The system was
NOT set to do automatic DST changes, and had the DAYLIGHT_SAVINGS.COM
routine run to queue a time change at the appropriate time.

Since the time change (which worked) timestamps on mail sent and
received from the PCs (which also changed time correctly) is off by
two hours (early).  Mail received on the Alpha and read locally shows
the correct time.  The PCs are in the correct (central CDT) timezone
and show the correct time locally.

We're in the central timezone.  Offset when daylight savings time is
active should be -05:00 (standard time is -06:00).  The
SYS$TIMEZONE_DIFFERENTIAL logical showed the expected, but no other
*timezone* logicals were set.

"SYS$TIMEZONE_DIFFERENTIAL" = "-18000"

The POP and SMTP services were restarted, but that did not correct the
problem.  I cannot reboot this system for a while; I hope that doesn't
end up being required.

I reran the SYS$MANAGER:UTC$TIME_SETUP procedure and made sure
everything was set up.  Upon exiting the additional timezone logicals
were set:

  "SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
  "SYS$TIMEZONE_DIFFERENTIAL" = "-18000"
  "SYS$TIMEZONE_NAME" = "CDT"
  "SYS$TIMEZONE_RULE" = "CST6CDT5,M4.1.0/02,M10.5.0/02"

We restarted the POP server again (a faint hope that it reads the
differential on startup), but we're still getting the same problem. 
Mail time on the Alpha from a terminal is correct, but once sent to a
PC, its shown as 2 hours early.

Any thoughts?  Google and DSNlink searches have been unhelpful. 
Thanks...

Rich
CCS

Rich Jordan wrote:
> We restarted the POP server again (a faint hope that it reads the
> differential on startup), but we're still getting the same problem.
> Mail time on the Alpha from a terminal is correct, but once sent to a
> PC, its shown as 2 hours early.

POP server doesn't have to deal with timezone differential. It just spits out
messages where the date is part of the content of the message. If you use MAIL
to look at a message, you'll see the Date: line in the RFC822 header and it
should contain a description of the time (either GMT, a time offset to GMT, or
a known time zone.)

Normally, the time would be added by the mail client that created the message.
However, some SMTP servers will add a date of the PC client,s date is missing
or invalid.

What you would need to do is use VMSmail to send an email to some external
system, and on that external system, look at the full headers to see how the
VMS system encoded the date.

Then, you can do the reverse, send an email from an external system to your
VMSmail mailbox and from VMSmail , look at the RFC headers to see how the date
was encoded.

Note that when you look at VMSmail headers (as opposed to the RFC headers in
the VMSmail contents), the date is the date received on that node, not the
date of the message)

When the POP server takes a "pure" VMS mail message without RFC headers, the
POP server will fake RFC headers, at whcih point it will take the date of
message as source, at which point the time offset may be important.

JF Mezei wrote:
> Rich Jordan wrote:
> 
>>We restarted the POP server again (a faint hope that it reads the
>>differential on startup), but we're still getting the same problem.
>>Mail time on the Alpha from a terminal is correct, but once sent to a
>>PC, its shown as 2 hours early.
> 
> 
> POP server doesn't have to deal with timezone differential. It just spits out
> messages where the date is part of the content of the message. If you use MAIL
> to look at a message, you'll see the Date: line in the RFC822 header and it
> should contain a description of the time (either GMT, a time offset to GMT, or
> a known time zone.)
> 
> Normally, the time would be added by the mail client that created the message.
> However, some SMTP servers will add a date of the PC client,s date is missing
> or invalid.
> 
> What you would need to do is use VMSmail to send an email to some external
> system, and on that external system, look at the full headers to see how the
> VMS system encoded the date.
> 
> Then, you can do the reverse, send an email from an external system to your
> VMSmail mailbox and from VMSmail , look at the RFC headers to see how the date
> was encoded.
> 
> Note that when you look at VMSmail headers (as opposed to the RFC headers in
> the VMSmail contents), the date is the date received on that node, not the
> date of the message)
> 
> When the POP server takes a "pure" VMS mail message without RFC headers, the
> POP server will fake RFC headers, at whcih point it will take the date of
> message as source, at which point the time offset may be important.

I wasn't sure if the POP server did translate local to GMT.  There are a 
number of different peecees running a number of different outhouse 
versions, all giving the same results (2 hours off); the time setups on 
the peecees have been verified.  I'm going to try a Eudora client 
tomorrow just to be different.


We sent smtp mail from the Alpha to our local Domino server and 
earthlink webmail.  Time displayed for the received email was correct. 
Sent email from the Domino server (and from Earthlink webmail) to the 
Alpha; time displayed in VMSmail for both messages was correct.  Sent 
some more, used one of the peecees to POP the mail into outlook, time 
was off 2 hours.  I did not examine the headers (didn't think of it, and 
ran out of time) but will tomorrow.

Thanks for taking the time to respond.

Rich

Rich Jordan wrote:
> We sent smtp mail from the Alpha to our local Domino server and
> earthlink webmail.  Time displayed for the received email was correct.

Displayed time is really a computed value by the Email client that parses the
RFC header and takes the Date/time in the Date: value, adjusts it with the
time offset in the Date: header, and then adjusts it to the time offset of the
client itself.

A correct displayed time could be a coincidence of wrong Date in header
combined with wrong GMT offset in the PC !

> Sent email from the Domino server (and from Earthlink webmail) to the
> Alpha; time displayed in VMSmail for both messages was correct.

VMSmail time is irrelevant since it is set by VMSmail irrespectice of the
Date: field in the RFC header. It is time when VMSmail actually processes the message.

Problem found.  Suitable applications of "Are you sure" and "Please
check again" applied to peecee users at the (remote) site revealed
that in fact, and despite several previous "confirmed" checks to the
contrary, the peecees had all decided to be in a different timezone. 
Nobody claimed responsibility but red faces were noted.

Silly peecee users... sigh...

Rich