gnus date suggestion

gnus date suggestion

[Jason R. Mastaler]

Don't you think it would be more standard and helpful for gnus to
display the day of the week in the "Date" mail header by default?

Gnus =       Date: 12 Jan 1997 13:17:58 -0500

MH/Mozilla = Date: Sun, 12 Jan 1997 14:06:24 -0500

ELM/Pine =   Date: Sun, 12 Jan 1997 14:08:29 -0500 (EST)

Re: gnus date suggestion

[David Moore]

jason@mastaler.com (Jason R. Mastaler) writes:

> Don't you think it would be more standard and helpful for gnus to
> display the day of the week in the "Date" mail header by default?
>
> Gnus =       Date: 12 Jan 1997 13:17:58 -0500
> MH/Mozilla = Date: Sun, 12 Jan 1997 14:06:24 -0500
> ELM/Pine =   Date: Sun, 12 Jan 1997 14:08:29 -0500 (EST)


	Yeah, that might be nice, or more generally provide you with a
format for displaying article times.  Gnus currently uses
timezone-make-date-arpa-standard to generate those times, but that is
only truly needed in message.el for outgoing messages.

	It'd be great to be able to use format-time-string for this.
And I just spent an hour trying to fake it out to do so, but it's not
friendly enough.


Thoughts & proposal:

	Being able to do that helps a lot with strftime in general,
which is why one should try to provide that functionality whenever
you make strftime available to people.  And also the ability to tell it
not to use 'localtime' on the time but 'gmtime'.  This is great, because
you can then use strftime to display time deltas conviently also.  If
something runs N seconds, but you want it in hour, minute, second format
you just do (format-time-string "%H:%M:%S" (list 0 N) t).

	And if you want'd to have differently displayed time messages in
Gnus, you could use something like:

(defcustom gnus-article-time-format "%a, %b %d %Y %T %Z"
  "Format for display of Date headers in article bodies.
See `format-time-zone' for the possible values."
  :type 'string
  :group 'article)


(defun gnus-art-make-date (date &optional local timezone)
  (let ((tz-date (timezone-fix-time date local timezone)))
    (format-time-string "%a, %b %d %Y %T %Z"
			(encode-time (aref tz-date 5) (aref tz-date 4)
				     (aref tz-date 3) (aref tz-date 2) 
				     (aref tz-date 1) (aref tz-date 0)
				     (aref tz-date 6))
			(aref tz-date 6) ; let %Z get the right name
		  ))
    ))


Proposed changed interface to format-time-string:

format-time-string: (FORMAT-STRING TIME &optional ZONE)
  -- a built-in function.
Use FORMAT-STRING to format the time TIME.
TIME is specified as (HIGH LOW . IGNORED) or (HIGH . LOW), as from
`current-time' and `file-attributes'.
FORMAT-STRING may contain %-sequences to substitute parts of the time.
ZONE defaults to the current time zone rule.  This can be a string
(as from `set-time-zone-rule'), or it can be a list
(as from `current-time-zone'), or an integer (as from `decode-time')
applied without consideration for daylight savings time, or it can be
T which specifies the time is a delta rather than a true time.


	I would like to see this, or equivalent functionality, in
xemacs (and gnu emacs), and I'm quite willing to code it, if there is a
consensus on how it should be done.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In cloud bones of steel.

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

David Moore <dmoore@UCSD.EDU> writes:

> 	Yeah, that might be nice, or more generally provide you with a
> format for displaying article times.

I've now added your new variable and code to Red Gnus 0.81.

> Proposed changed interface to format-time-string:
> 
> format-time-string: (FORMAT-STRING TIME &optional ZONE)
>   -- a built-in function.
> Use FORMAT-STRING to format the time TIME.
> TIME is specified as (HIGH LOW . IGNORED) or (HIGH . LOW), as from
> `current-time' and `file-attributes'.
> FORMAT-STRING may contain %-sequences to substitute parts of the time.
> ZONE defaults to the current time zone rule.  This can be a string
> (as from `set-time-zone-rule'), or it can be a list
> (as from `current-time-zone'), or an integer (as from `decode-time')
> applied without consideration for daylight savings time, or it can be
> T which specifies the time is a delta rather than a true time.
> 
> 	I would like to see this, or equivalent functionality, in
> xemacs (and gnu emacs), and I'm quite willing to code it, if there is a
> consensus on how it should be done.

Hm...  I think using a t value for a delta seems a bit kludgy.
Perhaps we should just have a different function?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: gnus date suggestion

[Jason R. Mastaler]

David Moore <dmoore@UCSD.EDU> writes:

> > Don't you think it would be more standard and helpful for gnus to
> > display the day of the week in the "Date" mail header by default?
> >
> > Gnus =       Date: 12 Jan 1997 13:17:58 -0500
> > MH/Mozilla = Date: Sun, 12 Jan 1997 14:06:24 -0500
> > ELM/Pine =   Date: Sun, 12 Jan 1997 14:08:29 -0500 (EST)
> 
> 
> 	Yeah, that might be nice, or more generally provide you with a
> format for displaying article times.  Gnus currently uses
> timezone-make-date-arpa-standard to generate those times, but that is
> only truly needed in message.el for outgoing messages.
> 
> 	It'd be great to be able to use format-time-string for this.
> And I just spent an hour trying to fake it out to do so, but it's not
> friendly enough.
> 
> 
> Thoughts & proposal:
> 
> 	Being able to do that helps a lot with strftime in general,
> which is why one should try to provide that functionality whenever
> you make strftime available to people.  And also the ability to tell it
> not to use 'localtime' on the time but 'gmtime'.  This is great, because
> you can then use strftime to display time deltas conviently also.  If
> something runs N seconds, but you want it in hour, minute, second format
> you just do (format-time-string "%H:%M:%S" (list 0 N) t).
> 
> 	And if you want'd to have differently displayed time messages in
> Gnus, you could use something like:
> 
> (defcustom gnus-article-time-format "%a, %b %d %Y %T %Z"
>   "Format for display of Date headers in article bodies.
> See `format-time-zone' for the possible values."
>   :type 'string
>   :group 'article)
> 
> 
> (defun gnus-art-make-date (date &optional local timezone)
>   (let ((tz-date (timezone-fix-time date local timezone)))
>     (format-time-string "%a, %b %d %Y %T %Z"
> 			(encode-time (aref tz-date 5) (aref tz-date 4)
> 				     (aref tz-date 3) (aref tz-date 2) 
> 				     (aref tz-date 1) (aref tz-date 0)
> 				     (aref tz-date 6))
> 			(aref tz-date 6) ; let %Z get the right name
> 		  ))
>     ))
> 
> 
> Proposed changed interface to format-time-string:
> 
> format-time-string: (FORMAT-STRING TIME &optional ZONE)
>   -- a built-in function.
> Use FORMAT-STRING to format the time TIME.
> TIME is specified as (HIGH LOW . IGNORED) or (HIGH . LOW), as from
> `current-time' and `file-attributes'.
> FORMAT-STRING may contain %-sequences to substitute parts of the time.
> ZONE defaults to the current time zone rule.  This can be a string
> (as from `set-time-zone-rule'), or it can be a list
> (as from `current-time-zone'), or an integer (as from `decode-time')
> applied without consideration for daylight savings time, or it can be
> T which specifies the time is a delta rather than a true time.
> 
> 
> 	I would like to see this, or equivalent functionality, in
> xemacs (and gnu emacs), and I'm quite willing to code it, if there is a
> consensus on how it should be done.

Did anything ever come of these suggestions and propositions?
I still think the Gnus "Date:" header format is non-standard.
I also noticed VM 6.29 under 19.15 XEmacs Lucid doesn't have this
limitation.

Gnus = Date: 01 May 1997 09:40:20 -0400
VM   = Date: Thu, 1 May 1997 09:53:01 -0400 (EDT)

-- 
Jason R. Mastaler                                 jason@mastaler.com

Re: gnus date suggestion

[François Pinard]

[Hi, people.  Sorry if this is a duplicate.  The message bounced.]

jason@mastaler.com (Jason R. Mastaler) writes:

| > > Don't you think it would be more standard and helpful for gnus to
| > > display the day of the week in the "Date" mail header by default?
| > >
| > > Gnus =       Date: 12 Jan 1997 13:17:58 -0500
| > > MH/Mozilla = Date: Sun, 12 Jan 1997 14:06:24 -0500
| > > ELM/Pine =   Date: Sun, 12 Jan 1997 14:08:29 -0500 (EST)

| Did anything ever come of these suggestions and propositions?
| I still think the Gnus "Date:" header format is non-standard.
| I also noticed VM 6.29 under 19.15 XEmacs Lucid doesn't have this
| limitation.
| 
| Gnus = Date: 01 May 1997 09:40:20 -0400
| VM   = Date: Thu, 1 May 1997 09:53:01 -0400 (EDT)

The nice thing (?) is that we have so many standards to chose from.
Some are definitely more more questionable than others, and using local
American dates for international mail has always been and is still very
questionable.  I seriously suggest that we switch to ISO 8601, which is
a much more sounded standard, and truly international.  Take a look at:

	http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html.

For example, Gnus should ideally display dates as:

	Date: 1997-01-12 13:17:58-05:00

A lot of people over the world (and even some people in United States :-)
are rather comfortable with this.

-- 
François Pinard                                 pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info

Re: gnus date suggestion

[Jason R. Mastaler]

pinard@iro.umontreal.ca (François Pinard) writes:

> The nice thing (?) is that we have so many standards to chose from.
> Some are definitely more more questionable than others, and using local
> American dates for international mail has always been and is still very
> questionable.  I seriously suggest that we switch to ISO 8601, which is
> a much more sounded standard, and truly international.  Take a look at:
> 
> 	http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html.
> 
> For example, Gnus should ideally display dates as:
> 
> 	Date: 1997-01-12 13:17:58-05:00

It still doesn't have the day of the week in it.  :-)

> A lot of people over the world (and even some people in United States :-)
> are rather comfortable with this.

Well maybe.  I'm sure there are alot of people that wouldn't be
comfortable with it.  I don't want to debate standards.  David Moore
originally had a suggestion of making this customizable with 
a format for displaying article times.  I think this should appeal
TO everyone.  He even offered to code it providing a consensus on how
it should be done was reached.  Maybe we should focus on this?

-- 
Jason R. Mastaler                                 jason@mastaler.com

Re: gnus date suggestion

[François Pinard]

"Jason R. Mastaler" <jason@mastaler.com> writes:

| pinard@iro.umontreal.ca (François Pinard) writes:
| 
| > I seriously suggest that we switch to ISO 8601, which is a much more
| > sounded standard, and truly international.  Take a look at:
| > 	http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html.

| David Moore originally had a suggestion of making this customizable
| with a format for displaying article times.  I think this should appeal
| TO everyone.

Lars has always shown vivid interest in internationalisation of Gnus.

Internationalising a program is preparing it so it can later be localised
for various habits and countries.  We should well identify if a program (or
part of a program) has been internationalised.  Those programs (or parts)
could then easily be bent to national habits, if not even personal taste.

In widely distributed programs, and for those parts *not* having been
internationalised, international standards should always prevail over
national standards.  Moreover, such international standards should also be
selected even for internationalised parts, when localisation information
has not been provided or otherwise selected by users.

The usual wrong thing with dates is using local American habits in wide
distribution contexts (like mail and news) for when programs have *not*
been internationalised, or by default.  ISO 8601 would be a good default.

-- 
François Pinard                                 pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info

Re: gnus date suggestion

[Hrvoje Niksic]

pinard@iro.umontreal.ca (François Pinard) writes:

> The usual wrong thing with dates is using local American habits in
> wide distribution contexts (like mail and news) for when programs
> have *not* been internationalised, or by default.  ISO 8601 would be
> a good default.

Gnus is news software.  For a newsreader, I think it's best to heed
RFC1036.

2.1.2.  Date

    The "Date" line (formerly "Posted") is the date that the message was
    originally posted to the network.  Its format must be acceptable
    both in RFC-822 and to the getdate(3) routine that is provided with
    the Usenet software.  This date remains unchanged as the message is
    propagated throughout the network.  One format that is acceptable to
    both is:

                      Wdy, DD Mon YY HH:MM:SS TIMEZONE
[...]


I don't think ISO 8601 is allowed by RFC822, but I may be wrong.
SoR1036 is even stricter when defining the `Date':

    5.1. Date

    The  Date header contains the date and time when the article
    was submitted for transmission:

	 Date-content  = [ weekday "," space ] date space time
	 weekday       = "Mon" / "Tue" / "Wed" / "Thu"
		       / "Fri" / "Sat" / "Sun"
	 date          = day space month space year
	 day           = 1*2digit
	 month         = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun"
		       / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
	 year          = 4digit / 2digit
	 time          = hh ":" mm [ ":" ss ] space timezone
	 timezone      = "UT" / "GMT"
		       / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
	 hh            = 2digit
	 mm            = 2digit
	 ss            = 2digit
	 zone-name     = 1*( <ASCII printable character except ()\> / space )

    This is a restricted subset of the MAIL date format.

As you can see, Gnus already emits the correct date, but having the
weekday would be desirable both for humans and rfc recommendation.

I think following ISO 8601 would be the wrong thing in this case.
Yes, internationalization is a fine thing.  But here we are talking
about Usenet software.  If the software we help create doesn't conform
to the RFCs, how can we expect the others to conform?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> I think following ISO 8601 would be the wrong thing in this case.
> Yes, internationalization is a fine thing.  But here we are talking
> about Usenet software.  If the software we help create doesn't conform
> to the RFCs, how can we expect the others to conform?

Indeed.  However, RFC1036 is currently being reformed, and perhaps we
can get the next RFC to allow (or recommend) ISO 8601 dates.

To subscribe to the mailing list, send a mail to
"usenet-format-request@clari.net".  I have yet to work out how to send
a mail to the mailing list itself; they have a weird filter thing set
up.  Or something.  There were no instructions in the sign-on message,
and there were no bounces.  I think the messages were simply dropped.
I'm not amused.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus date suggestion

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Indeed.  However, RFC1036 is currently being reformed, 

Is it?  Where?  What?  Something newer than son-of-rfc1036?  (I have
some stuff I deeply disagree with in that one).

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> > Indeed.  However, RFC1036 is currently being reformed, 
> 
> Is it?  Where?  What?  Something newer than son-of-rfc1036?  (I have
> some stuff I deeply disagree with in that one).

Write to usenet-format-request@clari.net to subscribe.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus date suggestion

[Jason R. Mastaler]

Hrvoje Niksic <hniksic@srce.hr> writes:

> As you can see, Gnus already emits the correct date, but having the
> weekday would be desirable both for humans and rfc recommendation.

Exactly.  Thats what I've been saying.  Thanks for adding the
associated excerpt's from the RFC's.

-- 
Jason R. Mastaler                                 jason@mastaler.com

Re: gnus date suggestion

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

Hrvoje Niksic <hniksic@srce.hr> writes:

| I don't think ISO 8601 is allowed by RFC822, but I may be wrong.

ISO 8601 is not allowed by RFC 822.  RFC 822 discourage the transmission
of all 8 bits either.  RFC 822 has such a few signs of obsolescence.

A great number of sites are nevertheless transmitting 8-bit mail.  I think
RFC's are there to help trigger progress, and they usually do at the time
they are written.  But it comes a time where some RFC's are inhibiting
progress, and when that time comes, we should stay able to move forward.
I give reason to those using 8bit channels for transmitting mail (the
EHLO protocol is fine) despite what RFC 822 may say.  I hope the same
will happen for dates.  Let's be more progressive than submissive! :-)

-- 
François Pinard                          mailto:pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info

Re: gnus date suggestion

[Greg Stark]

The dates in messages must be in RFC-822 format, don't be silly.

However, it would be useful for gnus to be able to display the dates in
whatever localized date format the user asked for. I'm not sure if there's a
global handling of localization features or date formatting code yet, if not i
would urge anyone interested in seeing dates in non-american formats to look
at gnus-art.el and timezone.el and write a small package for formatting dates
according to local conventions. 


PS:

someone said:
> When you write `123', you do not ask yourself if `2' is the number of
> hundreds, tens, or units.  Hopefully, many people share this convention
> that going left to right goes from more to less significative.

You must have missed the last twenty years of computer history, ask someone
what the terms "little-endian" and "big-endian" mean. Then ask what byte-order
PDP11 used.

Re: gnus date suggestion

[Johan Danielsson]

pinard@iro.umontreal.ca (François Pinard) writes:

> The usual wrong thing with dates is using local American habits in
> wide distribution contexts (like mail and news) for when programs
> have *not* been internationalised, or by default.  ISO 8601 would be
> a good default.

Yes, but ISO 8601, although intuitive to me, is not very friendly to
people used to other ways of writing dates, such as americans. 

The usual question with all-numbers date formats, "is 1997-05-03 the
third of May or the fifth of March", is the same question I always ask
when I see 05/03/97 (or is it 03/05/97?).

The best (IMO) way to write dates that should be understood by an
international audience is something like 1997-Mar-03, which pretty
much leaves us with RFC-822.

/Johan

Re: gnus date suggestion

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

joda@pdc.kth.se (Johan Danielsson) writes:

| pinard@iro.umontreal.ca (François Pinard) writes:
| 
| > The usual wrong thing with dates is using local American habits in
| > wide distribution contexts (like mail and news) for when programs
| > have *not* been internationalised, or by default.  ISO 8601 would be
| > a good default.
| 
| Yes, but ISO 8601, although intuitive to me, is not very friendly
| to people used to other ways of writing dates, such as americans.

You might have been educated by Americans :-).

There are other cultures in this world than the American one.  The trend
is considering that for international matters, choices should not always
nor necessarily be American by default.

| The usual question with all-numbers date formats, "is 1997-05-03 the
| third of May or the fifth of March", is the same question I always ask
| when I see 05/03/97 (or is it 03/05/97?).

When you write `123', you do not ask yourself if `2' is the number of
hundreds, tens, or units.  Hopefully, many people share this convention
that going left to right goes from more to less significative.
This convention usually goes without saying, and people do not feel
lost or mixed, they do know that `2' counts tens in `123'.  ISO 8601
just adopted this convention "year, month, day", from most to least
significative, exactly like numbers.  Sorting ISO 8601 dates is a simple
and straightfoward matter.  The convention is logical, and easy to
remember, just like for digits in numbers.  Further, in many countries,
really, people find it natural and easy going.  That is why 8601 got
accepted as an international standard.  I agree that American dates are
often confused.  That's yet another reason for not taking these dates
as models.

| The best (IMO) way to write dates that should be understood by an
| international audience is something like 1997-Mar-03, which pretty
| much leaves us with RFC-822.

`Mar' is surely not best, for a month.  Definitely not best.  If you start
with American dates and stop to American dates, you are left with RFC 822,
that's true.  We have to think wider.

-- 
François Pinard                          mailto:pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info

Re: gnus date suggestion

[Kyle Jones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1098 bytes --]

François Pinard writes:
 > joda@pdc.kth.se (Johan Danielsson) writes:
 > 
 > | pinard@iro.umontreal.ca (François Pinard) writes:
 > | 
 > | > The usual wrong thing with dates is using local American habits in
 > | > wide distribution contexts (like mail and news) for when programs
 > | > have *not* been internationalised, or by default.  ISO 8601 would be
 > | > a good default.
 > | 
 > | Yes, but ISO 8601, although intuitive to me, is not very friendly
 > | to people used to other ways of writing dates, such as americans.
 > 
 > You might have been educated by Americans :-).
 > 
 > There are other cultures in this world than the American one.

Have patience.  We've only gotten serious about the business of
assimilating/squashing other cultures within the last twenty
years.  These things take time. :-)

 > The trend is considering that for international matters,
 > choices should not always nor necessarily be American by
 > default.

True, but there's no reason to antagonize Americans on purpose,
is there?  The fact that Americans might be confused is a valid
complaint, isn't it?

Re: gnus date suggestion

[Johan Danielsson]

Kyle Jones <kyle_jones@wonderworks.com> writes:

> Have patience.  We've only gotten serious about the business of
> assimilating/squashing other cultures within the last twenty
> years.  These things take time. :-)

It would be nice if you could invent a culture of your own, before
starting to squash other's. ;-)

>  > The trend is considering that for international matters,
>  > choices should not always nor necessarily be American by
>  > default.
> 
> True, but there's no reason to antagonize Americans on purpose,
> is there?  The fact that Americans might be confused is a valid
> complaint, isn't it?

Right. The way to write dates in a non-decreasing order is not an
american invention either. The traditional way to write short dates in
Sweden in is 7/8-97, for todays date.

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.

/Johan

Re: gnus date suggestion

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Kyle Jones <kyle_jones@wonderworks.com> écrit:

|  > The trend is considering that for international matters, choices
|  > should not always nor necessarily be American by default.
|  > [Implying gnus and other things could favor ISO 8601 better.]
| 
| True, but there's no reason to antagonize Americans on purpose, is there?
| The fact that Americans might be confused is a valid complaint, isn't it?

The purpose has never been to antagonize Americans, but to use
international dates rather than American dates in software meant to be
use all around the planet.  Software like Gnus, say! :-)

Complaints may be valid, of course, but they loose part of their validity
if they inhibit progress.  The fact that American dates are confusing or
not very acceptable in some countries is also a valid complaint, and this
latter complaint is more prone to triggering real progress.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: gnus date suggestion

[Jason R Mastaler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 822 bytes --]

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

> The purpose has never been to antagonize Americans, but to use
> international dates rather than American dates in software meant to be
> use all around the planet.  Software like Gnus, say! :-)
> 
> Complaints may be valid, of course, but they loose part of their validity
> if they inhibit progress.  The fact that American dates are confusing or
> not very acceptable in some countries is also a valid complaint, and this
> latter complaint is more prone to triggering real progress.

This thread never seems to die.  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."

Why are you still picking on Gnus?

Re: gnus date suggestion

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On 21 Oct 1997 13:03:10 MDT, Jason R Mastaler said:
> This thread never seems to die.  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."

Except as modified by RFC1123, section 5,2,14, which addressed the Y2K
problem (in Oct 1989 no less).

I only bring this up because an anal-retentive RFC822 parser that is
not RFC1123-cognizant will run into some indigestion in some 801 days.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 284 bytes --]

Re: gnus date suggestion

[François Pinard]

Jason R Mastaler <jason@4b.org> écrit:

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

> This thread never seems to die.

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

> 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."

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

I do no really know how RFCs are handled, and I presume it is quite an
undertaking to produce new ones.  Further, not all RFCs get implemented.
So, I feel that this lapidary suggestion sounds more like "Get lost!" than
a practical one.  A few people working in ISO fields exchange letters
with me at various occasions, and I happened to read that ISO often prefer
making standard out of habits or usages, than forcing new habits through
the production of new standards.  So I think we should address habits
and usages more directly.  Standardisation might more easily follow, later.

> Why are you still picking on Gnus?

Please be kind enough to read the messages you are replying to.  I wrote:

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

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

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

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

> > 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."
> 
> I quite understand that some people do not even want to hear that there is
> a problem.  There is a problem nevertheless.

Sure.  But we have a situation where all current software supports
RFC822 Date headers, and parsing those headers aren't all that
difficult.  So we have something that 1) works, and 2) is widely used,
so there is no impetus for change.

Whenever I store times/dates externally, I use ISO 8601 (uhm, I think
I just forgot the name of the standard) dates, because it's such a
nice standard.  Not to use it for new things is just silly.  However,
it does not therefore follow that one should try to redesign most of
the common universe for little real gain.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus date suggestion

[Kyle Jones]

I'm sure that I've lost track of the point of this discussion.
François, what exactly are you advocating?

Re: gnus date suggestion

[François Pinard]

Kyle Jones <kyle_jones@wonderworks.com> écrit:

> I'm sure that I've lost track of the point of this discussion.
> François, what exactly are you advocating?

Not much: that we stay open minded to writing of international dates,
use all opportunities we get to switch, and always be careful to *also*
recognise international dates wherever software parse dates.

It would also be nice if software was offering to display dates as
ISO dates, would it imply a conversion at display time.  A `Wash Dates'
feature, in Gnus terms :-).  People could write and see ISO dates, and soon
consider American dates as some Quoted-Printable equivalent for dates :-).

Jason R Mastaler <jason@4b.org> écrit:

> Please be kind enough to followup to these discussions more frequently
> than every two or three months.

I surely would if I had more free time, yet there is no emergency to do
it all in a rush.  Those things take time, anyway.  Most of the work to do
is of human nature, for us to get more aware.  As for technical problems,
they are fairly easy to solve, at least within the free software world.

Lars Magne Ingebrigtsen <larsi@gnus.org> écrit:

> Sure.  But we have a situation where all current software supports
> RFC822 Date headers, and parsing those headers aren't all that difficult.

Parsing by software?  Yes, no problem there.  Parsed by a human, it stays
awkward for many non-Americans.  ISO 8601 is not only more logically
organised, it also does not impose English words or abbreviations.

> However, it does not therefore follow that one should try to redesign
> most of the common universe for little real gain.

Software, and Gnus is a good example of this, is often made up of
myriads of accumulated details, many of which not being that important
by themselves.  However, driven by a unifying spirit with a vision,
such accumulation may yield tremendous results.  Internationalisation is
somewhat similar.  Details are only important through their accumulation.
ISO 8601 is a notable detail in this picture, and not a difficult one.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: gnus date suggestion

[Per Abrahamsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1152 bytes --]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> It would also be nice if software was offering to display dates as
> ISO dates, would it imply a conversion at display time.  A `Wash Dates'
> feature, in Gnus terms :-).

I suspect if you submit a patch with an iso-wash-date function, Lars
will add it to Gnus with no fuss.

> > Sure.  But we have a situation where all current software supports
> > RFC822 Date headers, and parsing those headers aren't all that difficult.
> 
> Parsing by software?  Yes, no problem there.

RFC 822 date headers are not easy to parse by software.

Both news and mail format standards are up for revision
currently.  You can participate in the work simply be subscribing to
the proper mailing lists.  For news, it is 

	<URL:mailto:usenet-format-request@clari.net>

I don't know the address for the new mail format standard, but I'm
sure someone here does.

In an uncommon strike of common sense, the current suggestion for date
header in the comming news standard is "whatever the mail guys come up
with".  ISO 8601 has been suggested, but they news people wisely
decided to leave that battle for the mail group.

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> It would also be nice if software was offering to display dates as
> ISO dates, would it imply a conversion at display time.  A `Wash Dates'
> feature, in Gnus terms :-).  People could write and see ISO dates, and soon
> consider American dates as some Quoted-Printable equivalent for dates :-).

I've now added this to Quassia 0.24.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus date suggestion

[Jason R Mastaler]

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

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

I always read the messages I reply to.  Please be kind enough to
followup to these discussions more frequently than every two or three
months.  After many weeks go by, we tend to forget the details of your
rantings.  Thanks.

Re: gnus date suggestion

[Stephen J. Turnbull]

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.

Re: gnus date suggestion

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> 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.

I thought ISO 8601 was widely supported by many Asian countries?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus date suggestion

[David Moore]

pinard@iro.umontreal.ca (François Pinard) writes:

> For example, Gnus should ideally display dates as:
> 
> 	Date: 1997-01-12 13:17:58-05:00
> 
> A lot of people over the world (and even some people in United States :-)
> are rather comfortable with this.

The point was let a user customize the format times are shown to them
(even when using time washing operations like W T l, W T o, W T u, etc).
This is totally independent of the format which gnus to send out mail,
which would not be changed.  The problem is that it's currently hard to
show in other time formats (including the one you prefer) for times in
time zones other than your local one.

the suggested modification allows for this.  hopefully it'll appear in
xemacs 20.3.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

Re: gnus date suggestion

[Ken Raeburn]

pinard@iro.umontreal.ca (Frangois Pinard) writes:

> 	Date: 1997-01-12 13:17:58-05:00

Looks fine to me.  I don't want to get in the middle of this issue.
But it might be nice to get timezone-parse-date to return "-05:00" for
the time zone in this case rather than "-05" as it does now (in Emacs
19.34).

Of course, I don't know if Gnus ever retains the timezone.  But if
it's going to be returned, it ought to at least be correct.

Re: gnus date suggestion

[Paul Graham]

since both of the are legal (by my reading of rfcs 822 and 1123) i don't
understand the objection to the gnus format.

    jason> I still think the Gnus "Date:" header format is non-standard.  I
    jason> also noticed VM 6.29 under 19.15 XEmacs Lucid doesn't have this
    jason> limitation.

    jason> Gnus = Date: 01 May 1997 09:40:20 -0400
    jason> VM = Date: Thu, 1 May 1997 09:53:01 -0400 (EDT)


-- 
 paul
    pjg@acsu.Buffalo.EDU    |public keys at:
                            |     http://urth.acsu.Buffalo.EDU/~pjg/key.html
    if the above contains opinions they are mine unless marked otherwise.

Re: gnus date suggestion

[Jason R. Mastaler]

Paul Graham <pjg@acsu.buffalo.edu> writes:

> since both of the are legal (by my reading of rfcs 822 and 1123) i don't
> understand the objection to the gnus format.

I don't object to the format necessarily.  I just think having the
day of the week as part of the Date header is more intuitive, and
more widely used among MUAs and newsreaders, and therefore more
preferable.

-- 
Jason R. Mastaler                                 jason@mastaler.com

Re: gnus date suggestion

[David Moore]

[ apologies for duplicates, i seem to have only sent this to the xemacs
  list, rather than also to ding.  the downsides of a to-address group
  parameter ]

jason@mastaler.com (Jason R. Mastaler) writes:

> David Moore <dmoore@UCSD.EDU> writes:
> > Proposed changed interface to format-time-string:
> > 
> > format-time-string: (FORMAT-STRING TIME &optional ZONE)
> >   -- a built-in function.
> > Use FORMAT-STRING to format the time TIME.
> > TIME is specified as (HIGH LOW . IGNORED) or (HIGH . LOW), as from
> > `current-time' and `file-attributes'.
> > FORMAT-STRING may contain %-sequences to substitute parts of the time.
> > ZONE defaults to the current time zone rule.  This can be a string
> > (as from `set-time-zone-rule'), or it can be a list
> > (as from `current-time-zone'), or an integer (as from `decode-time')
> > applied without consideration for daylight savings time, or it can be
> > T which specifies the time is a delta rather than a true time.

we decided this was a good thing to do.  i just have been way too busy
this term at school to implement it.  final form was not to have the 't' 
special case, since you can just use "GMT" to the same result, I think.
you can either consider it something that will happen when i get time,
or something you could write today.

so this is on my list of things to implement when i get some free time.
that and cleaning up extent/text-prop speedup patches, which i want in
xemacs 20.3.


-- david

Re: gnus date suggestion

[Steven L Baur]

David Moore <dmoore@UCSD.EDU> writes:

> [ apologies for duplicates, i seem to have only sent this to the xemacs
>   list, rather than also to ding.  the downsides of a to-address group
>   parameter ]

It would be nice if there were some way to override this on the rare
occasions it is necessary.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: gnus date suggestion

[Hrvoje Niksic]

Steven L Baur <steve@miranova.com> writes:

> David Moore <dmoore@UCSD.EDU> writes:
> 
> > [ apologies for duplicates, i seem to have only sent this to the xemacs
> >   list, rather than also to ding.  the downsides of a to-address group
> >   parameter ]
> 
> It would be nice if there were some way to override this on the rare
> occasions it is necessary.

Why don't you use `S w' (and `S W') when you want to override it?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!" 
"They are my innards! I will not have them misread by a poseur!"

Re: gnus date suggestion

[Per Abrahamsen]

David Moore <dmoore@UCSD.EDU> writes:

> [ apologies for duplicates, i seem to have only sent this to the xemacs
>   list, rather than also to ding.  the downsides of a to-address group
>   parameter ]

Use `to-list' instead.