RE: Strange procps behavior with 1.5.0?

["Chris January" <chris at atomice dot net>]

> On Mon, Jul 07, 2003 at 09:30:13AM -0400, Christopher Faylor wrote:
> >On Mon, Jul 07, 2003 at 09:25:25AM +0100, Chris January wrote:
> >>> Anyone else see strange dates when you do a 'procps auwx' under
> >>> 1.5.0?  The latest snapshot is very close to 1.5.0, if you just want
> >>> to use that.
> >>>
> >>> I'm seeing dates in the future, like Jul20 and Jul21.
> >>
> >>I'll take a look at this tonight.
> >
> >I guess this was also broken in 1.3.22 (and maybe forever?) so it's not
> >technically a regression, but it would be nice to get it fixed.  AFAICT,
> >the process time calculation is just using raw Windows times, which
> >doesn't seem right.  You have to apply some factor to windows time to
> >get UNIX time.  See times.cc.
>
> Any word on this, Chris?
This is an old problem caused, IIRC, by hibernation or suspend. Basically
start_time is defined as "The time in jiffies the process started after
system boot." Now if you suspend or hibernate the computer, then resume, no
'jiffies' elapse while the computer is suspended. However the procps command
assumes they do because it has no concept of suspend or hibernate.
The current calculation for start_time looks wrong for me although it is too
long ago to remember why I did it that way in the first place.
Try:
       start_time = (put.CreateTime.QuadPart - stodi.BootTime.QuadPart) * HZ
/ 10000000ULL;
although I have a feeling that doesn't work for some reason.
I can't try it here because I'm using ssh to access the Cygwin machine so I
can't update the Cygwin DLL.

Basically it's a balancing act - get the values right in one place and they
will be wrong in another.

Chris