Re: gnus date suggestion

["Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>]

I think this thread is off-topic for both ding and
xemacs-beta-discuss.  It belongs on a mailing list devoted to
MIME-munging of the displayed form of messages in standard format,
IMHO.  Eg, SEMI, since that seems to be what François uses.

The rest is just justification of that position.

>>>>> "François" == François Pinard <pinard@iro.umontreal.ca> writes:

    François> Don't worry, this thread will die by itself when the
    François> problem would have been have addressed, rather than
    François> ignored.

So address it.  Write the functions, preferably as a standard library.
Call it "display-date" or the like.  Implement several functions for
converting to/from RFC-822 dates which are (a) easily machine parsable
and (b) standard and therefore _universally_ machine parsable.  Don't
forget the identity for people who want to read RFC-822 dates.

Define and document a standard API for those functions.  Add generic
display/input date function variables (like the various conventions
used for yanking mail, etc) which will hold the current versions for
the user's preference.  Then start converting the software.  Any
software which is MIME-compatible allows display to be different from
the content.

The definition part is about an evening's work (most of the work is
already done in rfc822.el)---for someone who cares.  Sorry, that's not
me.  Converting any given software can be done quickly and kludgily in
about 5 minutes since most support "post-message-display" hooks.

A better overall approach for many people is to integrate it into the
display-munging packages, eg, MIME drivers like SEMI.

    >> As Johan Danielsson said two months ago when this was last
    >> brought up, "Enough of this now. The way to write dates in mail
    >> messages is defined by RFC822. If anyone want's to change this,
    >> just write a new RFC."

    François> I quite understand that some people do not even want to
    François> hear that there is a problem.  There is a problem
    François> nevertheless.

Not with RFC-822, but with user agents' use of that data.  As long as
you fail to make that distinction, people instinctively know this is a 
non-problem.

    François> I do no really know how RFCs are handled, and I presume
    François> it is quite an undertaking to produce new ones.

Not really, if you've got a small simple idea that does not break
existing standards (as far as I can tell from looking at the text of
many existing RFCs---much of the work seems to be verifying the "does
not break" clause).  But in this case you can't win.  There is a
perfectly servicable Internet standard which satisfies (a) and (b)
above.  Noone in their right mind would change the format of the
messages themselves.

Any sysadmin can read RFC-822 dates.  (Hey, I know several people who
can read the output of `printf("%d\n",time())'.)  No need to change
the message format; people who do `less /var/spool/mail/$USER' had
better be able to handle it---there are a lot less friendly things
than RFC-822 dates lurking in there.

So, what needs to be done is to fix the display functions in the user
software, not the message content.

    François> Further, not all RFCs get implemented.  So, I feel that
    François> this lapidary suggestion sounds more like "Get lost!" 

Yup.  It wasn't polite, but I sympathize with his feeling, as you can
probably tell.

    François> than a practical one.  A few people working in ISO
    François> fields exchange letters with me at various occasions,
    François> and I happened to read that ISO often prefer making
    François> standard out of habits or usages, than forcing new
    François> habits through the production of new standards.  So I

Sometimes the various standards bodies simply adopt somebody else's
standard more or less whole.  If there was no definition of date
format in RFC-822, it would be trivial to adopt ISO-8601.

    François> think we should address habits and usages more directly.

That's a good approach where possible.  Here it's not.  There are
strong habits and usages opposing the "international" date format.  To 
implement it, you would have to make RFC-822 a configuration option.
This is not a recipe for redefining the standard, it's a recipe for
destroying it altogether.

Note the variant spellings of "standardization" in the next few lines.
Who's going to adopt whose standard here?

    François> Standardisation might more easily follow, later.

Wrong.  Standardization has _already_ happened.  However, as long as
the message date is in THE standard RFC-822 form user agents like Gnus 
can choose to display it anyway they like.

    >> Why are you still picking on Gnus?

    François> Please be kind enough to read the messages you are
    François> replying to.  I wrote:

    François>    The purpose [...] [is] to use international dates
    François> rather than American dates in software meant to be use
    François> all around the planet.  Software like Gnus, say! :-)

Yup, you're picking on Gnus.  The point is that you're on the wrong
level.  I note that your message was written with SEMI.  Although this
is (barely) out of the scope of MIME per se, I think, it's a MIME-ish
kind of thing to do.  Howcum the SEMI ML isn't on the addressee list?

    François> Here, we have an international standard opposing an
    François> oldish American standard.  Gnus might elect to favour

Internet standards are international standards.  Most of the early
ones happen to be written by Americans and are often heavily biased by
that fact.  That doesn't make them any less international than the
Internet itself is.

Why should international software _favor_ anything?  Japanese and
Chinese will be rather pissed off that you call ISO 8601 "the"
international standard.  The Oriental date format has been absolutely
standard for a couple thousand years, AFAIK.

    François> the international standard, instead of standing still
    François> until absolutely everyone agrees.  Most people know that
    François> RFC 822 will never be the driving force for any kind of
    François> improvement, as it already did most of its good, and
    François> thanks to it, Internet mail now exists.  Undoubtly, it
    François> was very helpful in its time, but it gets somewhat
    François> misused when as an excuse to slash out any further
    François> improvement.

Few RFCs are a "driving force for any kind of improvement."  Rather
they are flimsy, leaky bulwarks against the pestilences of Chaos and
Error.  The latter, of course, invariably present themselves as
Further Improvement.

ISO 8601 _is_ further improvement.  I think that display of dates in
the more rational ISO-8601 form makes a lot of sense as an option.
But noone will ever choose it.  Once the option is there, they'll
demand display in local forms.

I think that encoding dates in mail headers in the more rational
ISO-8601 form makes a lot of sense as a standard---if there were no
preexisting standard.  However, from the point of view of machine
processing it is only a miniscule improvement over RFC-822.

At this stage, opposing RFC-822 makes _you_ look like chauvinist,
trying to impose costs on systems world-wide, including most European
systems, to simply change a fundamentally machine-oriented format to
be more human-readable---for a relatively small subset of humans.