Bug 815958

What is your /etc/sysconfig/clock setting of HWCLOCK?

It's (copied by typing)
SYSTOHC=""
TIMEZONE="Europe/Berlin"
FORCE_SYSTOHC="no"
BADYEAR="no"
SYSTOHC_DEVICE=""
USE_HWCLOCK="yes"
USE_ADJUST="no"

hm.  this is not a 12.1 system is it?

according to https://www.suse.com/releasenotes/x86_64/openSUSE/12.2/
the info from HWCLOCK has moved to /etc/adjtime, as described e.g. here

http://forums.opensuse.org/blogs/jdmcdaniel3/what-utc-gmt-time-possible-issue-opensuse-12-2-its-solution-116/

If that file does not exist on your install, you have been hit by bug#779440

On comment #3: Actually I upgraded the system from 12.1 to 12.3 after having reported the bug (hoping for improvement). My current /etc/adjtime has:
---
0.0 0 0.0
0
LOCAL
---

ok the topic is messy.  the proper fix, teaching windows to take the hardware clock in utc, seems to be there but not perfect yet:

http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html


Vojtech,

on SUSE, it looks to me, the kernel is by default storing and restoring time from hwclock at hibernate/resume.  looking at the kernel source, it will do that using UTC, not some local time.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/rtc

esp. class.c and rtc-lib.c

which btw also means:  never ever boot windows on a hibernated machine...


on the other hand, at some point preparations had been made to explicitely sync the hardware clock with the system clock at suspend/resume:

https://gitorious.org/opensuse/pm-utils/blobs/master/pm/sleep.d/90clock

do you think that should be the hook to use for the case hwclock is set to local time?

I'm not sure, it just calls hwclock --systohc and hwclock --hctosys. This probably has the same effect as the kernel function, that's why the hook has this line:


is_set "$NEED_CLOCK_SYNC" || exit $NA

Which means it isn't used at all.

good that you came to the same conclusion that the script does nothing currently...


now I think this would be the place to take corrective action if hwclock uses local time instead of utc.

looking deeper into this, I suspect that with CONFIG_RTC_HCTOSYS=y, the kernel will not store the time as local time.  I think the kernel actually will never care about local time.  It looks to me as if local time is a userspace thing.


So for hwclock in local time, I think we'd need to disable CONFIG_RTC_HCTOSYS for that case, and then we'd need to modify the sleep.d/90clock script to save and restore the system clock on suspend and on resume.

Well we should avoid using pm-utils and try to replace their functionality with systemd so that they can be removed later, since they are dead upstream.

CC'ing Cristian, he usually knows how to do things without pm-utils.

systemd!  duh!
http://www.freedesktop.org/wiki/Software/systemd/timedated

well, I think we should really do some housekeeping and remove unused cruft from pm_utils.  this had never occurred to me.  We really need to remove dead code like sleep.d/90clock then...

anyhow:  christian, do you know whether the systemd implementation will handle DST switch during suspend gracefully?

Hrmmm.. keeping the CMOS in localtime and expecting this to work is not very realistic.

systemd-timedated knows when and why the next DST update will happend

 timedatectl
      Local time: lun 2013-04-29 12:19:38 CLT
  Universal time: lun 2013-04-29 16:19:38 UTC
        Timezone: America/Santiago (CLT, -0400)
     NTP enabled: n/a
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  sáb 2013-04-27 23:59:59 CLST
                  sáb 2013-04-27 23:00:00 CLT
 Next DST change: DST begins (the clock jumps one hour forward) at
                  sáb 2013-09-07 23:59:59 CLT
                  dom 2013-09-08 01:00:00 CLST

Buuut, timedated is not always running, it comes up when something tries to access its dbus interface.

I am not sure what to do about this, gonna ask somebody else ;-)

I know the subject is messy: IMHO the system needs to record the time when the hwclock was corrected for local time during DST change (just to avoid correcting it multiple times). Naturally the time of change should not be stored in local time for obvious reasons. To make matters worse in multi-boot environments, an other system (like Windows) can also adjust the hwclock. AFAIK, Windows/XP anly corrects the time if the system is powered on a few days after DST change; otherwise it assumes the hwclock is current. Sorry for throwing in some random thoughts. Rumors say recent Windows can work with hwclock running UTC, so there's light on the horizon...

If someone wants to take this bug and assign it to (him/her)self, it would be nice, since I can do nothing here.

Susanne, I will reassign this to you, since it seems to me that you are more likely to do something about this.
This has nothing to do with pm-utils anymore so I cannot help here.

Sadly release 12.3 is out of support. As such to keep cruft from our bugzilla please open a new ticket if you are still observing the issue.