Daylight savings transition does not happen if suspended

[Mary Gardiner]

Binary package hint: acpi-support

This is related to, but not I think the same as bug 36815, because writing to the hardware clock before suspending does not fix it.

Scenario: computer has hardware clock set to local time.
1. Computer is suspended
2. Transition into or out of daylight savings time occurs
3. Computer is resumed

The software clock will show the correct time zone post-transition, but will not actually update to the correct time, continuing to show the time that it would have been pre-transition.

I've described the same problem at https://launchpad.net/ubuntu/+source/tzdata/+bug/91418/comments/6 but I am not sure that bug 91418 is a complete duplicate or not, or whether there are two bugs.

[Steve Langasek (vorlon)]

I'm not sure what handles daylight savings transitions for systems that are /not/ suspended when the transition happens; but acpi-support is not involved with suspending in current versions of Ubuntu, so reassigning this to pm-utils as a starting point for further triaging.

[Scott James Remnant (Canonical) (canonical-scott)]

pm-utils no longer synchronises the system and hardware clocks over a suspend/resume cycle.

The rationale is that the kernel records the delta between the two clocks on suspend, and resets the system clock on resume based on this delta. The mix of the two can lead to strange issues such as you've seen (you either end up with no DST or double-DST).

We now just let the kernel do its thing.

Since the hardware clock will not change (and will just tick at its previous pre-DST value), when you come out of suspend, your system clock will still be in UTC (having had the delta restored). All userspace software uses this, and will apply the DST change properly.

The hardware clock is only changed to be DST-adjusted on shutdown.