[PATCH 1/4] Change the timezone filename format.

David Shea dshea at redhat.com
Wed Nov 6 14:32:35 UTC 2013


On 11/06/2013 02:50 AM, Vratislav Podzimek wrote:
> On Tue, 2013-11-05 at 17:01 -0500, David Shea wrote:
>> We don't need to use floating point to figure out the names of the
>> timzeone graphics, because we control the names of the timezone
>> graphics. Changed the offsets from a double number of hours offset from
>> UTC to a long number of seconds offset from UTC, which conveniently
>> matches the output of tz_location_get_utc_offset.
> To be honest, I don't like this change because it means we can no longer
> update the pixmaps easily from the "upstream" (Gnome Control Center)
> repository. Or is it still trivial? If not, could you please at least
> pull the latest pixmaps before this change?
>
Hm, ok. I didn't think about potentially resyncing with GNOME, and 
that's a good point. I agree that we should leave the filenames alone, 
but I am an old man from an old time when floating point operations were 
slow and untrustworthy, so I still feel like we should switch to 
fixed-point number in color_codes.offset. As far as synchronizing with 
GNOME's color_codes table: they haven't updated the table since the last 
time we did and they're missing the same time zones (UTC+14 most 
noticeably, which is that box in the eastern Pacific south of Alaska and 
near the equator). I'm also working on a test that will tell us when we 
have colors in cc.png that aren't matched by color_codes[], so we can 
use that after updating cc.png to tell what needs updating in the table.

I'm just worried that some kind of crummy ARM chip is going to introduce 
a rounding error when we divide by 3600 and mess up what should be a 
fairly straightforward filename lookup.


More information about the anaconda-patches mailing list