Hi Alex,
DST is not supported. Timezones are. The idea behind this was that a
backend application (like pmacct is) should ideally work only with UTC
(even if timezones are supported) and then front-ends should localize
the time as required.
DST doesn't introduce further side-effects to pmacct other than 1) the
one you described and b) when a SQL plugin is in use, entries are cached
in memory for up to 1 hour+sql_refresh_time when time is moved backward
(still timeslots are derived properly so this gets pretty transparent).
It could make sense to add the DST feature in pmacct but it's better to
determine the impact of that: checking if the DST setting changed since
the last packet/flow/sample would be the most straightforward solution,
maybe even the only possible, but certainly not the most efficient.
In saying all of this, I would also be happy to hear what others think
about DST support: ie. it's a dirty job, somebody has to do it: better
you than my humble scripts or rather this is something pmacct should not
end stuck with; if you see it implemented within pmacct, would you also
see it as a transparent feature or rather user-settable?
Cheers,
Paolo
On Tue, Apr 14, 2009 at 05:02:32PM +0300, alex wrote:
> Hello Paolo!
> Seems that I found a bug in realization 'sql_history' key.
> I use 'sql_history = 1d' value and when time switches to daylight saving
> (summer time) 'nfacctd' daemon starts to insert incorrect values into
> timestamp field ('stamp_inserted'):
>
> 10 0 0 0 192.168.5.49 0 0 0 tcp 0 4595652 4332277490 12350 2009-03-26
> 00:00:00 2009-03-27 00:00:01
> 10 0 0 0 192.168.5.49 0 0 0 tcp 0 5822132 5218820162 14684 2009-03-28
> 00:00:00 2009-03-29 00:00:01
> 10 0 0 0 192.168.5.49 0 0 0 tcp 0 3081249 2095939992 12018 2009-03-29
> 00:00:00 2009-03-30 01:00:01
> 10 0 0 0 192.168.5.49 0 0 0 tcp 0 4003156 3695428902 20109 2009-03-30
> 01:00:00 2009-03-31 01:00:01
> 10 0 0 0 192.168.5.49 0 0 0 tcp 0 2416080 2213229236 9547 2009-03-31
> 01:00:00 2009-04-01 01:01:01
>
> As you can see, 1 hour appears in 'stamp_inserted' value. However, daemon
> must round all time digits according to my configuration ('sql_history =
> 1d'). After I restart 'nfacctd' daemon, 'stamp_inserted' values have zero in
> hour position.
> I suspect that it is bug in mechanism of timestamp rounding.
> I use 'pmacct-0.11.4'.
>
> Thank you very much,
> Alex
>
> ---
> ??????? ?????? ??? - http://pogoda.tut.by
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
