Re: Total expiry not working -- is clock skew the problem?

[Ted Stern <dodecatheon@gmail.com>]

On  7 Feb 2006 at 19:37 UTC-0800, Katsumi Yamaoka wrote:
>>>>> In <lspy80nozf3.fsf@drip.ca.boeing.com> Ted Stern wrote:
>
>> One more note -- if I set expiry-wait to 0.0 on a topic, that works
>> perfectly.  It is only non-zero values that do not work.
>
>> On  7 Feb 2006 at 08:28 UTC-0800, Ted Stern wrote:
>
>>> I started a new job about 100 days ago and had to reconstitute my
>>> entire Gnus setup, almost from scratch.  In my old job, I had total
>>> expiry turned on and articles expired with no problems.  Now I have
>>> total expiry turned on in the group parameters for an entire topic,
>>> but nothing has expired automatically since day one.
>
> Well, you're talking about nnfolder groups, aren't you?

Yes, sorry for not being more specific!

> If so, how does the X-Gnus-Article-Number header in old articles
> look?  (You may need to type `t' in the summary buffer.)

Here is one example:

   X-Gnus-Article-Number: 1   Mon Nov  7 12:45:27 2005

This looks like it should be in the right format, right?

Other details:

- I have threads sorted by date, not number.  From ~/.gnus:

  (setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date)
  (setq gnus-thread-sort-functions
      '(
        (not gnus-thread-sort-by-most-recent-date)
        ))

- My mailing list email comes to me through a tortuous path:

    => gmail account, adding extra headers at beginning
    => fwd'd to company mail 
    => goes through company mail filter that filters for spam and adds
       extra headers
    => procmail, in which I filter out gmail forwarding headers at
       beginning.

So is it possible that Gnus is not seeing the X-Gnus-Article-Number
header because it comes after a bunch of other headers?

> For example, it should be something like:
>
> X-Gnus-Article-Number: 1234   Tue Feb  7 08:28:55 2006
>
> Where 1234 is an article number and the rest is a timestamp.  Gnus
> will look at this timestamp to decide whether to expire the article,
> so if there's no such header, the time stamp is corrupted or it
> shows a future date, expiring will not take place.  I have no more
> idea if those are going well.
>
> BTW, expiring might be executed in your machine eight hours earlier
> than the time specified with expiry-wait.  It is because the
> timestamp in the X-Gnus-Article-Number header is made by the
> current-time-string function and doesn't have a timezone info.  For
> instance:
>
> (progn
>   (setenv "TZ" "PST8PDT") ;; -0800
>   (/ (time-to-seconds (time-since (current-time-string))) 3600))
>  => 8.000075615555556

Aha.  This could be the problem.  There is a problem with time-since
input in my Emacs.

      (progn
        (setenv "TZ" "PST8PDT") ;; -0800
          (time-since (current-time-string)))

,----[ lisp debugger output, bytecode deleted and linebreaks added ]
| Debugger entered--Lisp error: (wrong-type-argument listp \
|   "Wed Feb  8 12:45:24 2006")
|   time-since("Wed Feb  8 12:45:24 2006")
|   (progn (setenv "TZ" "PST8PDT") (time-since (current-time-string)))
|   eval((progn (setenv "TZ" "PST8PDT") (time-since (current-time-string))))
|   eval-last-sexp-1(t)
|   eval-last-sexp(t)
|   eval-print-last-sexp()
|   call-interactively(eval-print-last-sexp)
|   recursive-edit()
|   byte-code("<weird byte code deleted so posting works>" \
|   [unread-command-char debugger-args x debugger-buffer noninteractive \
|   debugger-batch-max-lines -1 debug backtrace-debug 4 t backtrace-frame \
|   lambda 5 pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 \
|   "...\n" message "%s" buffer-string kill-emacs "" nil "" \
|   recursive-edit middlestart buffer-read-only standard-output] 4)
`----

Did you mean to use 'current-time' instead of 'current-time-string'?
In any case, I don't get any GMT/PST8PDT difference.

Ted
-- 
 dodecatheon at gmail dot com
 Frango ut patefaciam -- I break so that I may reveal