Here is log of a jabber conversation on this topic:
[18:32:50] *** [EMAIL PROTECTED] is Online
[18:48:50] <eugen> do you have any idea why calc_mac_epoch_diff() uses
year 1972 as reference?
[18:49:15] <eugen> for me that code looks very strange :(
[18:49:24] <[EMAIL PROTECTED]> no idea
[18:51:08] <eugen> the easiest 'fix' is to remove that assert, but I do
not know what can be a correct resolution
[18:54:08] <[EMAIL PROTECTED]> so, do you still get tracebacks without the
patch?
[18:54:23] <[EMAIL PROTECTED]> Perhaps I'll try to contact upstream
[18:56:43] <eugen> yes, I do...
[18:57:33] <[EMAIL PROTECTED]> weird, I couldn't reproduce them without
it, even going thru all the timezones listed on that page
[18:57:43] <[EMAIL PROTECTED]> and yours was one of them
[18:58:52] <eugen> I do not get traceback when I run "TZ=EEST ttx file"
[18:59:08] <eugen> but I do get them when I run "ttx file"
[18:59:16] <eugen> and my current TZ is EEST
[18:59:22] <eugen> strange...
[18:59:36] <[EMAIL PROTECTED]> hmmmm
[19:02:01] <eugen> hmm, without setting TZ time.daylight returns 1, if I
set TZ it returns 0
[19:03:50] <eugen> ...and time.{alt|time}zone return 0 when I set TZ...
[19:03:57] *eugen hates python
[19:05:52] <eugen> and TZ=Europe/Kiev works as expected29 квітня 2006 о 15:12 +0800 Paul Wise написав(-ла): > About http://bugs.debian.org/328098 > The problem has been found by other people after your patch was applied. > > I tested the problem using the timezones listed on this page: > > http://www.timeanddate.com/library/abbreviations/timezones/ > > With the patch, the following timezones fail: CET EET WET > > When I revert the patch, I am able to run the program fine using any of > the timezones, especially: EEST MEZ CET WET > > I think the solution here is to remove the patch, unless you have more > information. -- Eugeniy Meshcheryakov
signature.asc
Description: Digital signature
