| Summary: | ksysguard shows negative relative start time due to getting the timezone wrong | ||
|---|---|---|---|
| Product: | [Applications] ksysguard | Reporter: | Nicolas F. <kdebugs> |
| Component: | ksysguard | Assignee: | KSysGuard Developers <ksysguard-bugs> |
| Status: | REPORTED --- | ||
| Severity: | minor | CC: | arthur, bugseforuns, codestruct, g507839 |
| Priority: | NOR | ||
| Version: | 5.6.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
screenshot of negative startup times
another screenshot with tooltip showing absolute values |
||
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. |
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.