[Logwatch-Devel] Missing update from applystddate applyshttpdate and applyusdate

Bjorn L. bl_logwatch at mblmail.net
Fri Mar 18 11:03:08 MST 2005

laurent.dufour at havas.com wrote:
>>It also include a new patch in order to be able to extend the
> functionality of the --range option
>>In the --range option you can now do
>>and search for n days behind (" --range 2  is 2" days behind," --range 90"
> is 90 days behind and so on..)

I think those extensions to the --range option are useful.  One item
to consider is that, in addition to the three you modified, other files
also need to change, as they also attempt to parse the dates.  Here are
the files that interpret the --range parameter:


So I see different options in doing this:

1. Have each file parse the --range parameter (LOGWATCH_DATE_RANGE)
   based on its required format.  This is what we do now, and we would
   have to modify the remaining files.

2. Have a function in one file only that does the parsing.  The format
   is passed as a parameter, and a regular expression that matches the
   date range is returned.  The advantage is that most of the coding
   is done in one place, and allows for future changes more easily.

3. A search for function strftime shows that these are the formats

   format: %b %d                example: Mar 08
   format: %b %e                example: Mar  8
   format: %m/%d/%y             example: 03/08/05
   format: %m/%d                example: 03/08
   format: %Y                   example: 2005
   format: %a %b %d             example: Tue Mar 08
   format: %Y/%m/%d             example: 2005/03/08
   format: %d/%b/%Y             example: 08/Mar/2005

   Because all the above formats are mutually exclusive (a date
   in one format cannot be confused with another date in a different
   format), another option would be to simply return a regular
   expression that matches all the formats.  The advantage is that
   we could get rid of the scripts/logfiles/*/applydate files shown
   above, and the scripts would work across versions that change
   time formats.  The disadvantage is that every script would need
   to be checked to ensure they don't use the timestamp formats in
   unusual ways that might introduce bugs, and the processing of
   logs is less efficient.  [I don't think either of these are
   too time consuming, but I haven't tried it, either.]

I prefer options 2 or 3.

As a final note, there are a bunch of Perl modules that do date
and time processing.  We might be able to use one of those (I
haven't looked at them enough to have an opinion of the best
choices).  The advantage here might be not so much in simplifying
coding for the extensions to --range proposed above, as in allowing
more elaborate range options.

More information about the Logwatch-Devel mailing list