[Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale

Tue, 08 Jan 2002 16:05:23 -0800

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: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Barry Warsaw (bwarsaw)
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: 2002-01-08 16: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 00: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 06: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-30 23: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 14: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 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