[emacs-w3m:08485] Re: nnrss should borrow nnshibmun's RSS date processor...or something

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In [emacs-w3m : No.08484]
>>>>>	Mark Plaksin <happy@usg.edu> wrote:

> Here's one way to include the newer timezone-parse-date but it looks ugly
> and the Elisp docs say "In general, well-designed Lisp programs should not
> use this feature [eval-after-load]."

> (if (< emacs-major-version 22)
>     (eval-after-load "timezone" 
>       '(defun timezone-parse-date (date)
>          ... ;; include definition from Emacs 22
>          )))

This is similar to the way of APEL, with which I don't fully
agree.  One of the reasons is that it only hides imperfectness
of certain Emacs versions.

> Is there a better way or a better plan?

I think the best way at the present is yours, i.e., to make
nnrss always provide RFC822 date.  However, I still don't know
the reason why we should not use ISO 8601 date in nnrss
articles.  Though we might not be getting used to seeing it in
our eyes, I don't think that is so serious.

> If Gnus switches to date-to-time, then no change will be needed in nnrss,
> yes?

It will make several date-oriented features of Gnus, e.g.,
sorting, expiration, etc., work with ISO 8601 date.  However,
I'm not sure whether all those features actually work and are
actually used.  I can only say with certainty that they will
work with RFC822 date.

> I copied shimbun-rss-process-date, changed the first line from this:

> (luna-define-method shimbun-rss-process-date ((shimbun shimbun-rss) date)

> to this:

> (defun map-shimbun-rss-date (date)

> and then patched nnrss.el with the attached patch.

Thanks.  It looks good to me, and I seem to be able to rewrite
it in nnrss.el if we cannot use the shimbun code directly.

>> BTW, why do you prefer RFC822 date rather than ISO 8601 date?
>> If it is for the bugfix, we should apply it to both the Gnus
>> trunk and the v5-10 branch.

> I don't know enough to prefer either format :)  I was just trying to find a
> way to make nnrss show the correct date all the time.  Making nnrss able to
> do this in both the trunk and v5-10 sounds good to me though I only use
> trunk.

Does ISO 8601 date actually cause you pain, or give you any
trouble?  If so, we can call it a bug and we should fix it. ;-)