On recently started processes, ksysguard claims they have been launched -1 day and some hours ago. Hovering over the entry in the relative start time column reveals that it believes it has been started one hour in the future (possibly due to timezone or DST), and then makes a bogus calculation. Reproducible: Always # hwclock 2016-07-01 16:32:37.140183+1:00 # hwclock -c hw-time system-time freq-offset-ppm tick 1467383595 1467383595.038249 1467383605 1467383605.038727 48 0 ^C $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= $ timedatectl Local time: Fri 2016-07-01 16:34:23 CEST Universal time: Fri 2016-07-01 14:34:23 UTC RTC time: Fri 2016-07-01 14:34:23 Time zone: Europe/Zurich (CEST, +0200) Network time on: yes NTP synchronized: yes RTC in local TZ: no The output of ps -o start_time is actually the correct start time.
Created attachment 100950 [details] screenshot of negative startup times I encountered this issue today. It might be caused by resuming from stand-by. Rebooting fixed the issue.
Created attachment 100951 [details] another screenshot with tooltip showing absolute values
Confirmed for 5.10.4.
I also suspend/resume often, so it may indeed be related to suspending and resuming as opposed to anything to do with timezones.
Timezones do not explain this, because ksysguard always shows me relative start times that are days or weeks in the future. They are utterly wrong. I think the problems start after resuming the system from standby.
ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task. If your issue still happens with the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks!