Wrong time for cities added to world clock

[Jean-Baptiste Lallement]

In the screenshot attached timz for my TZ (GMT+2) is correct, but cities added to the 'World' section are not:
Boston/NY should be 8:52 instead of 2:50
London should be 13:52 instead of 15:52

(I am not talking about the minutes difference)

[Jean-Baptiste Lallement (jibel)]

and the screenshot

[Victor Thompson (vthompson)]

I tried to reproduce this but am unable to do so. Is this an issue only when the "Time & Date" in System Settings doesn't have a time zone populated?

[Nekhelesh Ramananthan (nik90)]

We do not use the System Setting time zone values. Currently we retrieve the timezone info of a location online. I think this bug occurs only for certain locations. Mostly likely the issue is due to the way the time difference is calculated which is causing incorrect values. Qt 5.2 finally brings support for timezones. So all one has to do is mention the timezone ID like "Europe/Amsterdam" and it will automatically show the correct time after accounting for day light saving rules. However I am not sure when Qt 5.2 will be used in the Ubuntu SDK. Until then I need to come up with a temporary solution.

[Victor Thompson (vthompson)]

"I think this bug occurs only for certain locations." If it is only dependent upon the location being queried, I tried Boston, NYC, and London and had no issues with any of them. Is it truly independent of local TZ?

[Nekhelesh Ramananthan (nik90)]

Victor it retrieves the current local time at the chosen location online and then subtracts it from the UTC time to calculate the time difference. It then applies this diff w.r.t the UTC time whenever the clock app is opened to show the correct time. The UTC time is independent of the local TZ.

[Victor Thompson (vthompson)]

Sure this is still valid? I set my timezone to UTC+2 then restarted and set the current location to the same city and still saw no issue. I even left my current location as UTC+2 and set my timezone as UTC+0 and the only issue was that my current location's time assumed it was UTC+0--that should be a bug.

[Nekhelesh Ramananthan (nik90)]

This has been fixed in the new clock app. The fix unfortunately cannot be backported easily since we need to introduce c++ plugins in the old clock app which will require a ton of fixes to the cmake files and so on which is not worth the effort considering that the new clock app will replace the old one in the near future (by the end of august 2014)