token age format [was: [cvs] common.h

David Relson relson at osagesoftware.com
Mon Dec 16 02:29:39 CET 2002


Guys,

I've been thinking about dates and formats.  There are at least three 
different things going on.

1 - internal format - how dates are stored in wordlists
2 - external format - how dates are dumped/loaded by bogoutil
3 - ages - how the user says "discard tokens older than X"

While time_t may be good for #1, it's not good for #2 or #3.

For #2, something human readable like yyyymmdd is more useful that the 
time_t equivalent.  For today, the two values would be 20021215 and 1040001069.

For #3, using "days" as the unit of measurement is good.  "Discard tokens 
older than 100 days" is easier than its time_t equivalent "discard tokens 
older than 8,640,000 seconds".

"A Plan for Spam" was published in August and /.'ed on August 16.  ESR 
started bogofilter around then (0.2 is dated Aug 22 and it's oldest file is 
dated Aug 18 05:51).  Bogofilter could assign an August 2002 date to tokens 
without dates and wouldn't be too far off.

David

At 06:23 PM 12/15/02, Greg Louis wrote:

>On 20021215 (Sun) at 1719:05 -0500, David Relson wrote:
> > At 04:58 PM 12/15/02, Matthias Andree wrote:
> >
> > >Better, but I'm not too comfortable with that now. Someone might want
> > >hour precision, someone else minute precision. There are ready-made
> > >functions to present or parse dates to/from time_t, you'll have to bring
> > >your own for "days since 2000-01-01".
> >
> > Matthias,
> >
> > Let's not forget the purpose of the value - to allow the discarding of old
> > tokens.  Let's also not forget how the capability is invoked, by a simple
> > "-a count" where count is a number of days.  I don't see a need for
> > precision, i.e. delete all tokens older than "3 months, 7 days, 13 hours,
> > 22 minuts".
>
>That doesn't seem to me to be the issue.  The issue is that there is a
>conventional and well-supported way to deal with timestamping, viz.,
>time_t and the functions that work with it.  There is much to be said,
>in regard to long-term maintainability/accessibility, for doing it the
>way it's normally done.  Reinventing wheels again... my vote, FWIW, is
>with Matthias on this one.
>
>--
>| G r e g  L o u i s          | gpg public key:      |
>|   http://www.bgl.nu/~glouis |   finger greg at bgl.nu |
>
>---------------------------------------------------------------------
>FAQ: http://bogofilter.sourceforge.net/bogofilter-faq.html
>To unsubscribe, e-mail: bogofilter-dev-unsubscribe at aotto.com
>For summary digest subscription: bogofilter-dev-digest-subscribe at aotto.com
>For more commands, e-mail: bogofilter-dev-help at aotto.com





More information about the bogofilter-dev mailing list