[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