+ Troy Morrison <[EMAIL PROTECTED]>:

| 
| | Because it is easier to track delays via Received: headers when they
| | all use the same time zone.
| 
| I don't mean to flame (I think this list is a little esoteric and
| hot-tempered as it is), but this seems like a bogus statement,
| considering that I haven't ever seen another MUA do this.

Received: headers are created by MTAs, not MUAs.  But yes, other MTAs
usually make time stamps in local time.  That doesn't mean it's a good
idea to do so, however.  And us qmail folks, we tend to be more
concerned with doing the Right Thing than doing whatever everyone else
does.  (Esoteric and hot-tempered, who?  8-)

| Is this a let's be different because we can mentality, or is there a
| better reason than this?

Perhaps it's a let's be different because different is better
mentality.  The other reason is that Dan is bending over backwards to
avoid using the standard C library for reliability and security
reasons.  And it is very very difficult to get good timezone
information without asking the standard C library.  But way back when
this was discussed (around version 0.96 or so?), it was me who raised
the point that timestamps in a single time zone were easier to
compare, which seemed to settle the discussion.

| | The only head field with a time which is intended for the end user is
| | the Date: field.
| 
| I suppose, then, that the "Date:" field in MAILER-DAEMON generated
| messages is not intended for the end user?

Heh, you got me there...  But really, what user wants to know *when*
the message bounced?  With mail from people, it *is* interesting to
know the sending date in their local time (for example, you can tell
that I am sending this a few minutes after midnight, which means I am
unlikely to make more followups to this thread for at least eight or
ten hours).  But with a bounce, knowing *why* is much more important.
Or if you want to know the bounce time, it may be of more interest to
relate it to your own time zone than that of the other end.  If your
time zone is +0700, it is probably easier to convert from UTC to your
local time zone than from, say, CDT.

- Harald

Reply via email to