Weather service does not add entry if city is selected but "Timezone" field is "Unknown"

Bug #291853 reported by komputes on 2008-10-31
6
Affects Status Importance Assigned to Milestone
libgweather
Fix Released
Medium
libgweather (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Ubuntu 8.10
gnome-applets 2.24.1-0ubuntu1

It seems that not all the cities listed comes with a timezone attached with it. Some cities such as Paris and New York work fine, they have a timezone attached to them, other cities do not have timezones need to be fixed. Some examples of these are:

Arviat, Nunavut
Yellowknife, NWT
Montreal, Quebec
Radisson, Quebec
Oral, Kazakhstan
Shymkent, Kazakhstan
Qyzylorda, Kazakhstan
Burwash Landing, Yukon

These are a few that I found but there are most likely many more. I think it would be wise to have all of the cities auto-complete this field so that the following does not reproduce itself. It give the impression that the applet is broken when in fact the user has no idea that the timezone field is required to add the entry to the list.

Steps to reproduce:

1) Click on the clock panel
2) Beside "Locations" select "Edit"
3) This will open a new window - In the "Locations" tab click "+ Add"
4) Put the name of any of the cities mentioned above
5) Press OK

What happens:
The city is not added regardless of actions taken. No alert is shown.

What is expected:
Either every city should automatically be associated with a Timezone or if this is not technically possible for some reason, prompt the user, or force the user to input the missing mandatory field.

Related branches

komputes (komputes) on 2008-11-01
description: updated
Sebastien Bacher (seb128) wrote :

thank you for your bug report, that's an upstream issue and should be sent to bugzilla.gnome.org

Changed in gnome-applets:
importance: Undecided → Low
Changed in libgweather:
status: Unknown → New
komputes (komputes) wrote :

Gnome bugs 559018 & 559031 are not getting any love.

Confirming this is still a bug in Jaunty Beta.

Changed in libgweather (Ubuntu):
status: New → Confirmed
Changed in libgweather (Ubuntu):
status: Confirmed → Triaged
Apteryx (maxco) wrote :

This bug is still present in Ubuntu 9.04 (install as well as live-cd), tested with amd64 build.
I can manually assign a time zone to my place, but there's a problem to retrieve the correct weather status (it says unknow when I hover over the weather applet). However, it displays the temperature accurately.

Apteryx (maxco) wrote :

I forgot a detail : the "Unknow" weather status can be seen when choosing location name : Montreal, Quebec, Canada (that's the one I tried). Also, after choosing this location, it displays under the "Locations" panel : Montreal | America/Toronto. I was wondering if this was correct, considering Toronto is ~550 km away from Montreal.

Thank you!

@Apteryx: This seems to be is a different problem. For me, the weather applet selects the Mc Tavish weather station at McGill instead of the PET Airport station, so it can't get more information than the temperature and wind speed. It can work even is the timezone is America/Toronto (which is just another way to say Eastern time for libgweather).

komputes (komputes) wrote :

Still an issue in Karmic, Montreal, Quebec, Canada still has no timezone

Proper time zone should be: Canada > Eastern Time

Apteryx (maxco) on 2009-10-09
Changed in libgweather (Ubuntu):
status: Triaged → Confirmed
Apteryx (maxco) wrote :

Oops.. Sorry for the "triaged -> confirmed". Didn't know I could play around with this? Seems I can't put it back to triaged.
Could someone put it back the way it was... thanks ;)

... or you could leave it confimed :) The problem occurs because some locations use timezones that are defined by libgweather as "obsolete", though the library does not attempt to match the obsolete names when searching for the time zones. For example, Montreal uses "America/Montreal", which is maked obsolete in the definition of "America/Toronto", but since libgweather does not parse the "obsoletes" tags, it can't find the time zone.

If I have some time, I will make a patch for upstream.

Changed in libgweather (Ubuntu):
assignee: nobody → Philippe Gauthier (philippe-gauthier)
komputes (komputes) wrote :

@Apteryx - Just for next time, know that "Triaged" status is better than "Confirmed" status as some developers only pay attention to bugs which have been completely triaged.

Can someone who has bug control permissions set this back to Triaged. Thanks.

Changed in libgweather (Ubuntu):
status: Confirmed → In Progress

@Philippe,

Thanks, your patch works perfectly. I've tested it with Montreal, Yellowknife, Oral and Qyzylorda with good results.

Attached is a script using the python-gweather package to test for this bug. With the latest fixes, libgweather returns the appropriate time zone identifier for each city specified in comment #1.

Also the branch has been updated to include the fixes from the recent 2.28.0-1ubuntu2 fix and has been renamed 2.28.0-1ubuntu3. Packages should be available soon in ppa:philippe-gauthier/ppa

Changed in libgweather (Ubuntu):
status: In Progress → Confirmed
Changed in libgweather (Ubuntu):
assignee: Philippe Gauthier (philippe-gauthier) → nobody
Apteryx (maxco) wrote :

@Philippe : How would someone go to compile your modifications?

I tried (excluding the apt-get install used to add the dependencies) :
bzr branch lp:~philippe-gauthier/libgweather/replace-obsolete-tzid.lp291853
cd ~replace-obsolete-tzid.lp291853
bzr builddeb

The build stopped when bzr saw I didn't have your gpg key, but at this step it had already compiled and output several deb files in the ~/build-area folder.

I installed successfully those four (4) generated debs, using gdebi :
libgweather-common_2.28.0-1ubuntu3_all.deb
python-gweather_2.28.0-1ubuntu3_amd64.deb
libgweather1_2.28.0-1ubuntu3_amd64.deb
libgweather-dev_2.28.0-1ubuntu3_amd64.deb

Then I rebooted (had to anyway, an upgrade had installed a new kernel).

After the reboot, there was no more meteo thingy beside the digital clock. I tried removing and putting back the calendar-hour app, but it didn't help. However, the independent meteo applet now displays the weather status.

So after applying your builds; I get :
 - No meteo nor temperature with the clock applet (right click, preferences, tick show meteo and temperature), even after choosing Montreal in "Places" (emplacements, in french).
 - Meteo and temperature for Montréal now works by adding the "meteo bulletin" applet.

I must be doing something bad. :)
Any help on this is welcome. Thank you for your work!

Apteryx (maxco) wrote :

I have great news : it works!

I was just being impatient, after forgetting about the absence of temperature in the clock applet for a few minutes, I was later surprised when I found it was displaying!

I confirm that the patch proposed by Philippe Gauthier works great. Merci :)

komputes (komputes) wrote :

Tested on Lucid, the issue is still present. Please try to get this patch in for the LTS release.

Changed in libgweather (Ubuntu):
status: Confirmed → Fix Committed
Sebastien Bacher (seb128) wrote :

the bug is fixed in lucid now!

Changed in libgweather (Ubuntu):
status: Fix Committed → Fix Released
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
komputes (komputes) wrote :

Confirmed this is resolved in Lucid. Fantastic work! Thank you.

Changed in libgweather:
status: New → Unknown
Changed in libgweather:
status: Unknown → Fix Released
Changed in libgweather:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.