Time didn't change itself after Daylight Saving Time started in Edinburgh

[Michal Predotka]

Today (29/03/2015) at 7:59 in the morning I've noticed the clock on my bq phone shows 6:59. I remember setting the time zone to "Edinburgh" when setting the phone. Today, when I opened the clock app I've seen this [1]. You can also notice that time for Warsaw is correct. Then I went to time and date settings. It displayed "UTC+0". I set "Time zone:" to Edinburgh again. After that it showed "UTC+1" and time was correct.
I must add that yesterday I set alarm on another device (Android phone) which thankfully woken me up on the right time. Otherwise my son's football training would be missed.

[1] see the attached screenshot, please.

[Nekhelesh Ramananthan (nik90)]

Thanks for reporting this bug. The clock app merely displays the system time. It does not have permission to change the system time. I suspect the issue is deeper within the system considering that the time&date settings shows Edinburgh time as "UTC+0" while it should have been "UTC+1" after the DST changes.

I must add that I didn't face this issue. Not sure why, but this seems to only affect some people. Can't find the common thing that triggers this issue.

[LionelB (retweet)]

I was interested to see what happened this morning. I am in England. No problem here, the time updated as it should.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

settings is only an UI to configure things, it's not running and responsible of changing time. The tz info come from tzdata and should the time shift should be applied by the system low level

[Adam Conrad (adconrad)]

tzdata is merely data. It doesn't *do* anything, and certainly doesn't magically change the time. It contains information on how to convert system time (UTC offset from the UNIX epoch) into the correct localtime, based on your $TZ selection or /etc/localtime, but it's up to applications displaying the time to actually call into the correct libc functions to give you an appropriate time.

Usually where this goes wrong is that people will ask glibc for a correct time once on startup, and then start an internal counter and increment that, never going back to check on reality.

Common fixes for this that don't cause intense load tend to be things like only checking localtime when each minute ticks over, or only checking when an application is actually displayed in the foreground. Obviously, the latter would be completely wrong for an alarm clock, and the former would cause unwanted wakeups on a phone, but one could be clever and ask about future stamps in advance, if you're setting up wakeup events.

ie: Ask the system to mktime your next alarm time (or next N alarm times) and store the correct wakeup events as neutral timestamps, so that even if DST happens while you're asleep, the next alarm happens correctly anyway.

[Adam Conrad (adconrad)]

(Ruled out as a bug in the actual data, given that the user found that manually changing his timezone from his own timezone to his own timezone -- a null op -- changed his time to be correct, proving that tzdata has the right offsets for his timezone, but the application in question had to be nudged to re-read it)

[Bartosz Kosiorek (gang65)]

After analysing the screenshot, it seems that system time was wronlgy set (top right corner).
If it will be Ubuntu-Clock fault, then the time between Clock and System clock will be different.

[Benjamin Drung (bdrung)]

Marking this bug as invalid for tzdata, because there is no indication that the timezone data were wrong.