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

[noreply@sourceforge.net]

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: 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