From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/13843 Path: main.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus date suggestion Date: Mon, 9 Feb 1998 12:49:37 +0900 (JST) Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035153136 11452 80.91.224.250 (20 Oct 2002 22:32:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:32:16 +0000 (UTC) Cc: "(ding) Gnus Mailing List" , XEmacs Beta Discussion List Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.8/8.8.8) with ESMTP id TAA20871 for ; Sun, 8 Feb 1998 19:54:09 -0800 Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by xemacs.org (8.8.5/8.8.5) with ESMTP id VAA22337 for ; Sun, 8 Feb 1998 21:51:10 -0600 (CST) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id WAN03825; Sun, 8 Feb 1998 22:27:27 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 08 Feb 1998 21:50:10 -0600 (CST) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by sina.hpc.uh.edu (8.7.3/8.7.3) with SMTP id VAA15598 for ; Sun, 8 Feb 1998 21:50:00 -0600 (CST) Original-Received: (qmail 10425 invoked by uid 504); 9 Feb 1998 03:49:55 -0000 Original-Received: (qmail 10422 invoked from network); 9 Feb 1998 03:49:54 -0000 Original-Received: from tanko.sk.tsukuba.ac.jp (HELO tanko) (root@130.158.99.155) by claymore.vcinet.com with SMTP; 9 Feb 1998 03:49:52 -0000 Original-Received: by tanko id m0y1kDx-00014SC (Debian Smail-3.2.0.98 1997-Oct-16 #4); Mon, 9 Feb 1998 12:49:37 +0900 (JST) Original-To: François Pinard In-Reply-To: X-Mailer: VM 6.34 under 20.4 "Beetal" XEmacs Lucid (beta11) Precedence: list X-Majordomo: 1.94.jlt7 X-MIME-Autoconverted: from quoted-printable to 8bit by altair.xemacs.org id TAA20871 Xref: main.gmane.org gmane.emacs.gnus.general:13843 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:13843 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 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.