This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: test_email assumes Unix uses NTP scale
Type: Stage:
Components: Build Versions: Python 2.2
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: barry, gvanrossum, prjsf, tim.peters
Priority: normal Keywords:

Created on 2001-12-27 21:44 by prjsf, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Messages (13)
msg8524 - (view) Author: Paul Jarc (prjsf) Date: 2001-12-27 21:44
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.
msg8525 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-28 21:54
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.
msg8526 - (view) Author: Paul Jarc (prjsf) Date: 2001-12-28 22:12
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.
msg8527 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-28 22:43
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.
msg8528 - (view) Author: Paul Jarc (prjsf) Date: 2001-12-31 07:18
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.
msg8529 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-31 14:34
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...
msg8530 - (view) Author: Paul Jarc (prjsf) Date: 2002-01-01 08:46
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?
msg8531 - (view) Author: Paul Jarc (prjsf) Date: 2002-01-09 00:05
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.
msg8532 - (view) Author: Paul Jarc (prjsf) Date: 2002-03-26 21:52
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.)

msg8533 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-03-27 01:31
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>.
msg8534 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-27 01:59
Logged In: YES 
user_id=6380

Thanks Tim for explaining it. I take responsibility for
closing this.

Leap seconds: Just Say No.
msg8535 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2002-03-27 03:21
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).
msg8536 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-03-27 04:14
Logged In: YES 
user_id=31435

Guido, I just want to be clear that the OP is fighting the 
bad effects of leap seconds too.  Leap seconds are part of 
the definition of UTC, but not part of the OP's preferred 
TAI.

POSIX mandates that time_t <-> struct tm conversions be 
computed as if every day had 86400 seconds, but because 
people using NTP (or other sync services) end up having 
clocks displaying UTC, the POSIX standard is forced to add:

"The relationship between the actual time of day and the 
current value for seconds since the Epoch is unspecified."

IOW, POSIX defines localtime() in such a way that there's 
no defined relationship between time_t values and what a 
box believes the time is.

I think POSIX gave up too easily here -- the result is 
unusable for many purposes.  So I sympathize w/ the OP.  At 
the same time, it's not Python's job to repair POSIX's 
shortcomings, and the POSIX rules are at least platform-
independent and predictable.
History
Date User Action Args
2022-04-10 16:04:50adminsetgithub: 35840
2001-12-27 21:44:29prjsfcreate