From: Just van Rossum <just@le...> - 2006-05-23 08:48:58
Paul Wise wrote:
> I'm the current debian maintainer for the fonttools package. When I
> adopted it, it had a bug about a traceback in certain timezones.
> The bug came with a patch, so I applied the patch. Later down the
> track other people had the same problem with the patch applied.
> I ran a script to check every timezone I have on my system.
> Without the patch I get tracebacks with the timezones mentioned in
> the bad-no-patch.txt attachment. With the patch, I get tracebacks
> with the timezones mentioned in the bad-patch.txt attachment. I also
> attached the output of running ttx with and without the patch. You
> can also see the values (time.gmtime(safe_epoch)[:6] first and
> safe_epoch_t[:6] second) just before the assertion errors.
> As to the fix for this, I don't know enough about fonts or fonttools,
> but shouldn't ttx be only dealing with GMT/UTC time? Surely fonts
> don't embed timezones in them?
> 1. http://bugs.debian.org/328098
> 3. for TZ in `find /usr/share/zoneinfo/ | sed
> s_^/usr/share/zoneinfo/__g | grep -v ^posix/ | grep -v
> do echo $TZ ; TZ="$TZ" ttx marlett.ttf ; done &> output ; grep
> -B 5 Traceback output | grep -v -- -- | grep -v Dumping | grep
> -v Traceback
> Here, marlett.ttf is the smallest ttf I could find on my
Are you working with an up to date cvs version of fonttools? There was a
patch checked in fairly recently for this. If that still doesn't work
correctly, I'm all ears for suggestions what to do.
On Tue, 2006-05-23 at 10:48 +0200, Just van Rossum wrote:
> Are you working with an up to date cvs version of fonttools? There was a
> patch checked in fairly recently for this. If that still doesn't work
> correctly, I'm all ears for suggestions what to do.
This is on a CVS snapshot from last year. I haven't updated it because
there were relatively few changes in CVS and I wanted to get this bug
fixed first. If you are referring to , I just tested that patch and
it did not help, because it doesn't catch the AssertionError thrown from
calc_mac_epoch_diff() in _h_e_a_d.py, it only catches ValueErrors from
another part of the code.
BTW, I'm not sure if it is correct, but the python docstrings for the
time module say that the correct way to get the epoch is to use
time.gmtime(0). On this machine, it gives (1970, 1, 1, 0, 0, 0, 3, 1, 0)
is there any reason that the code uses (1972, 1, 1, 0, 0, 0, 0, 0, 0)?
What exactly is calc_mac_epoch_diff supposed to do and why is it needed?