Cleverly, we don't report the DAY, just the TIME in the pmdumplog
output ... grr.
But, looks like it _really_ is for Oct 6!
$ date --date='TZ="UTC" 1970-01-01 00:00:00 +1223212334.242047sec'
Mon Oct 6 00:12:14 EST 2008
My theory is not correct unfortunately.
But I am sure pmdate reports the wrong thing in this boundary case, so
on the basis that it should be fixed, and I don't have any more evidence
from this particular event, and another one is not going to happen for
at best 6 months.
On Tue, 2008-11-25 at 10:48 +1100, Nathan Scott wrote:
> On Tue, 2008-11-25 at 10:38 +1100, Ken McDonell wrote:
> > Hmmm.
> >
> > Does not disprove my hypothesis, but does not prove it either.
> >
> > 20081006 is a bit odd. If pmdumplog -l reports an end time then the
> > archive is not really busted. But pmdumplog -v is a strange beast, that
> > looks like a pmdumplog bug (sigh).
> >
> > Just try pmdumplog 20081006 | head -100 ... the timestamps appear in the
> > pmResult dumps.
>
> I've attached two dump heads - one pmdumplog with no options,
> the other with -Dpdu (this one shows the raw timestamps).
>
> > But 20081006 looks like it is for the correct day which undermines my
> > theory.
> >
> > I believe the problem is in pmdate -1d when you're within an hour of
> > midnight and there was a DST adjustment in the previous 23-25 hrs ...
> > there is no good answer here, pmdate cannot produce the 100% right
> > answer no matter what.
>
> Yep, sounds entirely feasible.
>
> > I'm looking at reworking pmlogger_daily to remove all dependence on
> > pmdate, and this will give me a chance to re-instate the -o option ...
> > actually new behaviour to merge _all_ archives, not just yesterday's and
> > -o for the old (current) behaviour, so all of pmlogger_daily QA will
> > work again ...
>
> OK, great!
>
> cheers.
>
> --
> Nathan
|