[Mailman-Developers] Re: Dates

[David Champion]

On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>,
	"Jay R. Ashworth" <jra@baylink.com> wrote:
> > correct.  How would it possibly know?  You're discussing ways to make a
> > correct guess in most cases, but not a way to ensure correct
> > information in all cases.
> 
> Stipulated.  But we're not rewriting for retransmission, only to keep
> the archives clean; right, Barry?

That's what I understand, too.  My personal taste is that an archive
reflect with complete accuracy and fidelity what was received from the
transmitter -- not the recipient's interpretation thereof.  This is
only relevant to particulars of implementation, though, not to whether
the general solution is applied at all.  For example, I think it's more
appropriate to leave the default at "don't munge incoming mail at
all".


> > > Fine.  Then turn those switches off.  You're in a minority, many other
> > > people hate having *incorrect* (and they are incorrect -- those messages
> > 
> > I don't think the discussion thus far is sufficient to say who's a
> > minority, and I don't think that's relevant.  What matters is that
> > Barry seems to agree with you, and that not one has proposed a way to
> > make everyone happy.
> 
> Well, it's a matter of personal taste, to some degree... but we could
> always dig up Einar Stefferud and Marshall Rose, and see what they
> think. 
> 
> But as it happens, I agree with Barry, not the other way round.

Fine.  I suppose I used "agree" in the sense of having equivalent
opinion, not of changing one's mind to match another's.  I tend to
think of this commutatively.  Since I was speaking to you, and my
emphasis was on what Barry thinks rather than on what you think....


> not the time it was actually injected.  Now, while I don't think the
> standard actually *says* (section 3.3 certainly doesn't), *I* would
> personally assert that that field is invalid if the clock it was
> generated from isn't within *some* reasonable percentage of accurate
> (for a machine which is continuously connected to the Internet, I'd
> call that a second or so; for a machine *regularly* connected, probably
> 30-45 seconds).

Without looking, I would wager cash that the *standard-track* RFC
doesn't specify expected transmission time.  I think you perhaps expect
too much of the Internet.


> > This approach to the hypothetical problem doesn't cover all cases, just
> > the majority of cases where there's damage due to misconfiguration.
> 
> Where damage can be interpreted as "people getting annoyed about the
> behaviours of others based on messages with incorrect time stamps"?

Where "damage" means "undesired harm or inconvenience".


> I wasn't trying to suggest otherwise.  What I *can* be construed as
> trying to suggest is that, since the proposed solution can be switched
> on and off at will, popping up with "Well, *I* don't think it needs to
> be fixed cause I don't think it's a problem" seems, at best, not
> especially productive.  Particularly in light of the fact that *it's
> already done*.

I disagree, but we can each choose our crusades.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago