To: drums@cs.utk.edu
Subject: Re: timezones & Date 
In-Reply-To: Your message of "Sat, 06 Apr 1996 11:46:37 PST."
             <v03005b07ad8c76eced4f@[205.214.160.56]> 
Date: Sun, 07 Apr 1996 06:42:44 +1000
Message-Id: <5515.828823364@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Sat, 6 Apr 1996 11:46:37 -0800
    From:        Dave Crocker <dcrocker@brandenburg.com>
    Message-ID:  <v03005b07ad8c76eced4f@[205.214.160.56]>

    precision.  the date/time specifies a single second.  it should
    pertain to something with roughly that granularity of occurrence.

It would - the difference is whether you, as recipient, are
to be told exactly which "something" that happened to be.

But then, as you note below, we don't have the kind of time
synchronisation that allows this anyway, from many systems the
times are simply never that accurate - if we were to accept this
as something if genuine importance, we'd either be requiring
NTP synchronisation before allowing mail, or we'd be abandoning
Date: as useless.   Somehow I doubt either of those is on the
cards...

    a standard defines semantics.  why should the standard use
    semantics that are that fuzzy/imprecise, when others are
    available and reasonable.

And restrictive - when they don't need to be.

    The difference between when you started to compose your
    message and when you finished composing it can be much, much
    to large for that framework to be of any use.

That depends upon the use to which one may like to put it.
    
    So starting to write the note and then letting it sit for a week
    before going back to it for review and modification and, finally, sending,
    would show a week's delay for the message?  This doesn't sound very helpful
    to the recipient.

Of course it is, in many cases that is exactly what I want, in
exactly those circumstances.   I find it constantly irritating to
do exactly that, and then have to explain in great detail why the
first half of the message no longer makes as much sense as it
should given the apparent posting date.   If the recipient sees
that I started the message a week ago, then it will be more
readily obvious why the first several pages seem to be in total
ignorance of the phone call that we had just yesterday...

    On the other hand, I think your example has a basic flaw, the
    crux of which is that using date field information is in no
    way helpful in determining the exact order of thread
    composition, much less "thread awareness" by the contributor.

Not exact order, no - there is no "exact order" in threads anyway.
But after other information has been considered (References, etc)
the Date can give one extra useful bit of info to help things be
a little better placed - not perfect, just better.
    
    Your example failed to note that before you started composing your
    message there well might have been 10 other thread contributions on their
    way to you.  We would have no way of knowing whether you received them
    before or after writing your note.

That's right, you don't - but the closer the Date is to when I
started compositin the better you will do in placing it.  It will
certainly not makes things worse.  That perfection is not achieved
is not a fatal flaw, perfection is rarely achieved...
    
    (By the way, does anyone have privacy concerns about communicating
    how long it took an author to write a message?)

Gawd, of all things to worry about...   First, there is no such
information available, as it is never possible to tell in these
cases when the user actually pushed "send" as distinct from
when the first Received header was added - recall it is purely
because of this problem that we are having this discussion, if
mail was always processed when the user finished with it (ended
composition) we wouldn't have even thought to care about this
issue of when Date was added.

Second, it is probably much more of a privacy concern that you
can determine that I am awake and working at 06:40 than it is
that you could figure out (if you could) that this message took
15 minutes (or however long it is) to type.   That would be
another argument for dropping Date: altogether.
    
    >Thus, this should probably be a user controllable option, so people
    >can set whichever they prefer - but that's more than DRUMS need
    in which case the field has, literally, no standard meaning.
    either the semantics are standard or they aren't.  user-settable options
    like this primarily serve to undermine the utility of a standard.

Not at all.   The standard meaning can be "the user interacted
with the message in some way at time X".   That's a perfectly
valid and sane, and even useful, meaning.

It conveys less than "the user pressed send at time X", or
"the user pressed compose at time X", but conveying less is not
of itself necessarily a problem - it becomes so only if we have
a use for the data the requires more precision.

So far, apart from being there for the human recipient to look
at, and whatever role it has in thread sorting, I have yet to
see much of a specification for what use anyone might make of
Date - neither of those two uses needs it to be precise at any
particular instant in the compilation process.

kre