Received: from localhost (daemon@localhost) 
        by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
	id NAA19031; Thu, 21 Mar 1996 13:38:21 -0500
Received: by CS.UTK.EDU (bulk_mailer v1.4); Thu, 21 Mar 1996 13:38:03 -0500
Received: from leibniz.math.psu.edu (root@leibniz.math.psu.edu [146.186.130.2]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK)
	id NAA19005; Thu, 21 Mar 1996 13:38:01 -0500
Received: from augusta.math.psu.edu (augusta.math.psu.edu [146.186.132.2]) by leibniz.math.psu.edu (8.6.12/8.6.9) with ESMTP id NAA02886; Thu, 21 Mar 1996 13:37:52 -0500
Received: from localhost (barr@localhost) by augusta.math.psu.edu (8.7.3/8.6.9) with ESMTP id NAA13900; Thu, 21 Mar 1996 13:37:07 -0500 (EST)
Message-Id: <199603211837.NAA13900@augusta.math.psu.edu>
To: Dave Crocker <dcrocker@brandenburg.com>
cc: drums@cs.utk.edu
Subject: Re: timezones & Date 
In-reply-to: Your message of "Thu, 21 Mar 1996 09:32:26 PST."
             <v03005614ad7742759014@[205.214.160.57]> 
References: Your message of "Wed, 20 Mar 1996 23:37:11 CST." <v03005614ad7742759014@[205.214.160.57]> 
X-Face: $+9-wYg.[->94HJ{go[7Q]E!K&hUg7ZhLyCMyq_FU*ca0GazE>^/2BKLcK0bP-'%;Nn?M<m
 c~dP_j^A?M5Jw{+a7vcMu|M-mq"V4AzKq?mPMMNP\;f8J0n\-L]ODU)YMP;-pF>+am,jlSP>1K$iz@
 %'v'FEW{@](U&Ed/}>ju3Ctlr!XwJ27Q)7h2a%"`sz;j:/3EC[mXi@*X@HE1]'ddq$ZX"ePsMyTkeg
 >zdML.SV<t=R>vX1W`adGIUD
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 Mar 1996 13:37:06 -0500
From: Dave Barr <barr@math.psu.edu>

In message <v03005614ad7742759014@[205.214.160.57]>, Dave Crocker writes:
>At 8:09 AM 3/21/96, Dave Barr wrote:
>>Personally I'd like to see clients be discouraged from generating
>>Date:'s unless the client has a specific reason for generating its
>>own date (and can do so correctly!).
>>
>>The transport agent, or the interface to the local transport agent
>>should be the one generating the Date, IMHO.
>
>	This simply does not EVER generate the right date/time for
>disconnected users. 

I know, that's why I said "unless the client has a specific reason for
generating its own date".  That's also why I said it should be the
"interface to the local transport agent" which does the work.  For
example if you're offline, the client wouldn't add the Date: but
the date would be added by whatever software is involved in queuing
and later transmitting the message when the host came online.
(I'm taking a modular approach to the definition for those cases where there
are such modular boundaries -- in cases where there aren't it's still
obvious who's responsible for what task)

--Dave