Clock doesn't update after changing time zone

Bug #1271484 reported by Matthew Paul Thomas on 2014-01-22
76
This bug affects 18 people
Affects Status Importance Assigned to Milestone
indicator-datetime (Ubuntu)
High
Charles Kerr

Bug Description

indicator-datetime 13.10.0+13.10.20131023.2-0ubuntu1, Ubuntu 13.10

1. Open "System Settings" > "Time & Date".
2. Change the time zone. (And if bug 1102890 has been fixed, choose "Apply".)
3. Look at the clock in the menu bar.
4. In the "Clock" tab, toggle any of the "Weekday", "Date and month", or "Time in other locations" options.
5. In the "Clock" tab, toggle any of the "12/24-hour time", "Seconds", or "Time in auto-detected locations" options.

What happens:
3. The clock still shows the time in the previous time zone.
4. The clock still shows the time in the previous time zone.
5. The clock updates to the new time zone.

What should happen:
3. The clock shows the time in the new time zone, just like System Settings does.

This bug was previously fixed as bug 735445. On some systems the bug is masked by bug 1244680, where the clock freezes instead.

Related branches

description: updated
Sebastien Bacher (seb128) wrote :

I can confirm that the tz is not updated, but toggling seconds or 12/24 doesn't fix it here ... changing the auto-detection one does it though

Changed in indicator-datetime (Ubuntu):
importance: Undecided → High
status: New → Confirmed
assignee: nobody → Charles Kerr (charlesk)
Iain Lane (laney) wrote :

There's a quite similar issue on the phone too. Change the timezone in system-settings and the indicator doesn't reflect this.

Charles Kerr (charlesk) wrote :

This is fixed in https://code.launchpad.net/~charlesk/indicator-datetime/cpp/+merge/202719 for 14.04, but that MP is so different from 13.10 that 13.10 will need a different fix.

Charles Kerr (charlesk) wrote :

The 13.10 fix in lp:~charlesk/indicator-datetime/13.10-lp-1271484 is also part of that cpp MR for trunk and seb128 and I are both seeing that branch work on the Desktop.

There's a separate issue on the phone, though. For some reason the GFileMonitor that's watching /etc/timezone isn't emitting any 'changed' signals when /etc/timezone changes. Interestingly, it seems to be something about /etc/timezone itself.

For comparison, here's indicator-datetime running on the phone. In this run I've changed the compile-time flags to watch /tmp/tz instead and am editing that file inside of vi to switch between London and Chicago:

Indicator-Datetime-Message: timezone-file.cpp:32 ctor /tmp/tz
Indicator-Datetime-Message: timezone-file.cpp:62 setFilename(/tmp/tz)
Indicator-Datetime-Message: timezone-file.cpp:70 0x422045b8 is now monitoring /tmp/tz
Indicator-Datetime-Message: timezone-file.cpp:80 Monitoring timezone file '/tmp/tz', id is 2
Indicator-Datetime-Message: timezone-file.cpp:81 refcount is 1
Indicator-Datetime-Message: timezone-file.cpp:84 setFilename(/tmp/tz) calling reload now
Indicator-Datetime-Message: timezone-file.cpp:100 void unity::indicator::datetime::FileTimezone::reload()
Indicator-Datetime-Message: timezone-file.cpp:110 void unity::indicator::datetime::FileTimezone::reload() Europe/London
Indicator-Datetime-Message: timezone-file.cpp:91 FILE CHANGED!!
Indicator-Datetime-Message: timezone-file.cpp:100 void unity::indicator::datetime::FileTimezone::reload()
Indicator-Datetime-Message: timezone-file.cpp:110 void unity::indicator::datetime::FileTimezone::reload() America/Chicago
Indicator-Datetime-Message: timezone-file.cpp:91 FILE CHANGED!!
Indicator-Datetime-Message: timezone-file.cpp:100 void unity::indicator::datetime::FileTimezone::reload()
Indicator-Datetime-Message: timezone-file.cpp:110 void unity::indicator::datetime::FileTimezone::reload() Europe/London

Here's the same test and setup, using the standard /etc/timezone and swapping that one back and forth between London and Chicago. GFileMonitor doesn't emit any 'changed' signals in this setup:

Indicator-Datetime-Message: timezone-file.cpp:32 ctor /etc/timezone
Indicator-Datetime-Message: timezone-file.cpp:62 setFilename(/etc/timezone)
Indicator-Datetime-Message: timezone-file.cpp:70 0x422045b8 is now monitoring /etc/timezone
Indicator-Datetime-Message: timezone-file.cpp:80 Monitoring timezone file '/etc/timezone', id is 2
Indicator-Datetime-Message: timezone-file.cpp:81 refcount is 1
Indicator-Datetime-Message: timezone-file.cpp:84 setFilename(/etc/timezone) calling reload now
Indicator-Datetime-Message: timezone-file.cpp:100 void unity::indicator::datetime::FileTimezone::reload()
Indicator-Datetime-Message: timezone-file.cpp:110 void unity::indicator::datetime::FileTimezone::reload() Europe/London

Also, the automatic unit tests which use a local temporary file instead of /etc/timezone also work.

Sebastien Bacher (seb128) wrote :

Thanks Charles, I guess the monitor not working has to do with the hackery done on the phone to make the file writable...

Martin Pitt (pitti) wrote :

My strong suspicion is that this watches for /etc/timezone changes, but on the phone this never actually changes. This is just a symlink to /etc/writable/. So I suppose before you set up a file watch you do a realpath() call to ensure that you always watch for changes to the actual file.

Charles Kerr (charlesk) wrote :

pitti: I will try that and retest, thanks for the tip.

Charles Kerr (charlesk) wrote :

Martin, your guess was right -- realpath()ing the symlink resolves this bug on the phone.

Charles Kerr (charlesk) wrote :

The realpath() fix is in 14.04 now, and the original fix landed in 13.10 some time ago, so finally marking this bug as fixed...

Changed in indicator-datetime (Ubuntu):
status: Confirmed → Fix Released
Khurshid Alam (khurshid-alam) wrote :

Has this fix really landed on 13.10?

If I add a online calendar in evolution(for example RTM events public ical file) it shows wrong date & time in indicator-datetime even though it shows correct time in evolution. Evolution uses system timezone & ical file uses same time-zone as system-time zone.....using indicator-datetime (13.10.0+13.10.20131023.2-0ubuntu1.1) here.

It works fine on Trusty.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers