[Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 26 Mar 2002 19:21:55 -0800
Bugs item #497162, was opened at 2001-12-27 16:44
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470
Category: Build
Group: Python 2.2
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: test_email assumes Unix uses NTP scale
Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
File "./Lib/test/test_email.py", line 935, in
test_formatdate
self.assertEqual(gdate, matchdate)
File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'
This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock
values ambiguous, and complicates interval calculations.
So my clock counts *all* seconds since the epoch. It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.
----------------------------------------------------------------------
>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-26 22:21
Message:
Logged In: YES
user_id=12800
Thanks Guido and Tim for resolving this. BTW, the right way
to submit patches is to attach either context or unified
diffs to the bug report using the file upload feature of the
tracker. Be sure to click on the checkbox too, otherwise
your upload won't get attached (yeah, this sucks).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-26 20:59
Message:
Logged In: YES
user_id=6380
Thanks Tim for explaining it. I take responsibility for
closing this.
Leap seconds: Just Say No.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:31
Message:
Logged In: YES
user_id=31435
Presumably Barry believed other work had priority. You're
running an unusual configuration, and are the only one
asking for this change.
BTW, Python isn't assuming NTP, it's assuming either POSIX
compliance (which mandates the results Python is checking
for) or Mac compliance. Selling variations is much easier
when they're backed by common practice or a relevant
standard. Right or wrong, neither applies here. When we
toss in any old crap someone feels like having, we end up
with stuff like embedded spaces in filenames <wink>.
----------------------------------------------------------------------
Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:52
Message:
Logged In: YES
user_id=412110
This problem still exists in 2.2.1c2. Is there something wrong
with my patch? (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)
----------------------------------------------------------------------
Comment By: Paul Jarc (prjsf)
Date: 2002-01-08 19:05
Message:
Logged In: YES
user_id=412110
A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior. The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.
----------------------------------------------------------------------
Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 03:46
Message:
Logged In: YES
user_id=412110
Are the Mac folks aware that the spaces impact everyone else,
not just them?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 09:34
Message:
Logged In: YES
user_id=6380
Thanks for the patch. I'm assigning this to Barry, who wrote
the test.
Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...
----------------------------------------------------------------------
Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:18
Message:
Logged In: YES
user_id=412110
Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>
On a separate note, some patches would not be so easy simply
because of the filenames containing spaces. You might
consider renaming those files. This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:43
Message:
Logged In: YES
user_id=6380
If you want this fixed, please submit a patch.
----------------------------------------------------------------------
Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:12
Message:
Logged In: YES
user_id=412110
Most software will trust localtime() and gmtime() to
interpret the clock. It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other
use of the C functions, you check it against a precomputed
string, thus doubting the C functions. C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.
I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous. The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility. By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.
I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them. This will still fail for
people who use even more exotic setups, but I don't know of
any such. Is there anything wrong with this? I think the
benefit easily outweighs the cost.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:54
Message:
Logged In: YES
user_id=6380
I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470