Timezones, take 2

Vratislav Podzimek vpodzime at redhat.com
Thu Nov 7 13:40:02 UTC 2013


On Thu, 2013-11-07 at 07:42 -0500, David Shea wrote:
> On 11/07/2013 06:24 AM, Vratislav Podzimek wrote:
> > On Thu, 2013-11-07 at 09:59 +0100, Vratislav Podzimek wrote:
> >> On Wed, 2013-11-06 at 17:56 -0500, David Shea wrote:
> >>> Since our code is taken pretty directly from the datetime panel in
> >>> gnome-control-center, I'm leaving TimezoneMap.c alone as much as possible in
> >>> order the keep us more in sync with GNOME. I'll submit patches to
> >>> gnome-control-center upstream once I've worked out the wrinkles described
> >>> below. Sure would be nice if this thing was part of Gtk or a separate library
> >>> or something.
> >>>
> >>> Patch 1 is the one that pins locations to the zone that was clicked. I've fixed
> >>> the bug that Vratislav found in the last one, which was basically that I wasn't
> >>> converting between offset values right. I also added a check for whether a new
> >>> offset value was found at all, and don't update the location if it wasn't. This
> >>> means that the map can have dead spots: any spot in the map that does not have
> >>> a mapping between its color in cc.png and the data in TimezoneMap.c will fail
> >>> to choose a timezone offset, and any offset with no location in the tzdb will
> >>> fail to choose a location.
> >>>
> >>> To find those dead spots, enter patches 2 and 3: patch 2 checks for whether
> >>> colors defined in cc.png have matching entires in TimezoneMap.c and vice versa,
> >>> and patch 3 checks for whether each UTC offset defined in TimezoneMap.c has a
> >>> corresponding location. The answer to patch 3, after all of this, is still: no.
> >>> At least not in the zone.tab in F19 for UTC-1. I need to look at this more
> >>> closely to figure out if this is a bug in the tzdata or what.
> >>>
> >>> I added two more checks while I was at it: patch 4 checks that we have
> >>> highlight images for each entry in TimezoneMap.c and vice versa, and patch 5
> >>> ensures that there are no duplicate colors in the TimezoneMap.c definitions.
> >>>
> >>> The main problem, re: cc.png <-> TimezoneMap.c, was that whoever originally
> >>> created cc.png left in borders between timezones, which is not helpful when
> >>> you're trying to map between zones and arbitrary clicks. Ryan Lerch helped out
> >>> on that one by creating a handy XCF file that has each zone as a separate
> >>> layer, and the new cc.png is generated from that. Patches 7 and 8 fix the rest
> >>> of the problems, by removing an erroneous image and fixing the color_codes
> >>> table.
> >>>
> >>> For the last patch, I figured I should re-run autoscan after adding the tests,
> >>> so I did.
> >>>
> >>> The next step is to send this stuff up to gnome-control-center. Sure would be
> >>> nice if this thing was in a separate library.
> >> These all look good to me.
> > Taking back, sorry. I've found another bug which, I'm afraid, would be a
> > pain. The following two videos show the difference:
> > http://vpodzime.fedorapeople.org/tzmap_unpatched.webm
> > http://vpodzime.fedorapeople.org/tzmap_patched.webm
> >
> > The problem is that there are cities that are far away from "their
> > timezone", Kaliningrad being a nice example.
> >
> This is at least partly a problem in the images. Kaliningrad moved 
> forward an hour in 2011, and our map images and cc.png do not reflect 
> this. I can write a test case checking all of the offsets in the tz 
> locations against the offset we expect in cc.png, but it will be time 
> consuming to update the images, and the time zones are going to be a 
> moving target. Places like Kaliningrad should be big enough to be 
> clickable once fixed, but there are going to be cities here and there 
> with exclave zones so small that they're probably going to have to be 
> input by hand.
> 
> What do you think? Is it worth it to fix the map, or should we just 
> stick with the closest by distance regardless of zone?
I think that the improvement in the user experience is not so big to be
worth the amount of work that would be needed to fix the map. But, you
know, your mileage may vary.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list