Bugs item #497162, was opened at 2001-12-27 13: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: Wont Fix
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: Paul Jarc (prjsf)
Date: 2001-12-28 14: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 13: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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4