Hi, I've just committed into the CVS some code to slightly facilitate life of who uses pmacct on systems which automagically get the clock changed as effect of DST (Daylight Saving Time).
Shifts forward are handled smoothly: they are timely recognized and as a result the current time-bin (sql_history) and SQL cache scanner deadline (sql_refresh_time) are adjusted by "catching up" the time difference; an "if (now > X) then X += Y" was modified in a "while (now > X) then X += Y". Shifts backward were not a reason of prime concern (essentially as they get solved transparently); for the way DST works, it means having a day of 25 hours, with one hour repeated twice: whichever way these backward shifts are handled, they would still generate spourious results and hence i felt to not act on them - but as usual comments are welcome. As of now, what would happen is a 02:00AM entry accounting for the "real" time bin (say, 5mins, 1hr basing on the sql_history config) plus the full extra hour. The tricky alternative would be to bring the clock back and having the time-bins between 01:00AM to 02:00AM polluted with double data. Caveat for this approach being: it would not work whenever sql_dont_try_update is enabled - as it would just generate lots of duplicates. I've lab-tested the shifts forward working (for me); any additional testing from you is more than welcome. Cheers, Paolo On Mon, Aug 03, 2009 at 10:12:30AM +0300, alex wrote: > Hello Paolo, > Could you please tell about current state of this question. > > Alex > > >On 04/19/2009 01:00:48 PM, Paolo Lucente wrote: > >>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. > > > >I don't understand where the conversion to local time is happening > >regarding this problem, but what makes sense to me is to collect > >timestamps in UTC, store them in UTC when storing them in a database, > >and let whatever's pulling the data out of the db present the data > >to the user in whatever fashion makes sense. Any other approach, > >i.e. working in local time or DST, makes working across time zones > >difficult, and computing intervals (in the case of DST) impossible. > >(Because when you look at a time during the hour when DST moves > >the clock back you don't know which hour you are in.) > > > >As, it seems, timezones are supported, then those that want > >to struggle with an approach other than the above can already > >do so because timezones account for DST. I don't know what > >it means to support timezones and not support DST so don't > >know what DST support would mean. I would think that > >all the support for timezones, DST, and the like is already > >in the localization facilities supplied by the OS and > >that's where it should stay. > > > >Karl <k...@meme.com> > > --- > ??????? ?????? ??? - http://pogoda.tut.by _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
