Re: faster gnus-thread-latest-date

[Dan Christensen <jdc@uwo.ca>]

I'm now thinking that caching the parsed time in "time value" format (a
pair of integers) rather than a float might be more useful, since many
parts of Gnus need this information.  For example, gnus-dd-mmm and
gnus-user-date take the date in this format to produce the summary
lines.  If the user is using dates for sorting and in summary lines,
then the slow part (parse-time-string) will only need to be done once.

But in looking around the code, I noticed the following discrepancies:

In gnus-thread-latest-date, the time value is computed using

  (mail-header-parse-date (mail-header-date header))

and mail-header-parse-date is an alias for ietf-drums-parse-date, which
is defined to be (apply 'encode-time (parse-time-string string)).

On the other hand, *every* other part of Gnus that needs to convert
a date string to a time value uses date-to-time, which is defined
to be

  (apply 'encode-time (parse-time-string
                       (timezone-make-date-arpa-standard date)))

The comments near the last one suggest that this makes conversion
more robust.  However, it is 3 times slower than the first way.

Since everywhere else in Gnus uses the slower way, and we're going to
cache the output anyways, I guess the right thing to do is to switch
gnus-thread-latest-date to use date-to-time as well.

Once this is done, is there any reason to keep ietf-drums-parse-date
around?  It's not used anywhere else in the code that I can see.

Dan