Issue497162
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.
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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:50 | admin | set | github: 35840 |
2001-12-27 21:44:29 | prjsf | create |