On builder "AMD64 FreeBSD 8.2 3.x" for the TIME_MINYEAR:

======================================================================
FAIL: test_negative (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 397, in test_negative
    return super().test_negative()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 425, in test_negative
    self.assertEqual(self.yearstr(TIME_MINYEAR), str(TIME_MINYEAR))
AssertionError: '2147483648' != '-2147483648'
- 2147483648
+ -2147483648
? +

New changeset 9cb1b85237a9 by Florent Xicluna in branch 'default':
Issue bpo-13312: skip the single failing value for now.
http://hg.python.org/cpython/rev/9cb1b85237a9

New changeset d877d7f3b679 by Florent Xicluna in branch 'default':
Actually, there's more than one failing value. (changeset 9cb1b85237a9, issue bpo-13312).
http://hg.python.org/cpython/rev/d877d7f3b679

It fails for very low negative years:
-2147483648 <= year < -2147481748
(-1<<31) <= year < (-1<<31) + 1900

Every other value behaves correctly on this FreeBSD buildbot:

• (-1<<31) + 1900 <= year < (+1<<31) : correctly formatted with '%Z'
• year < (-1<<31) : raises OverfowError
• year >= (+1<<31) : raises OverfowError

I mean formatted with '%Y', of course.

New changeset 1a0bfc26af57 by Florent Xicluna in branch 'default':
Issue bpo-13312: skip the failing negative years for now.
http://hg.python.org/cpython/rev/1a0bfc26af57

The failing negative years test is still being skipped. I'm assuming this was not originally intended.

I believe that this can be closed as the test code was changed completely in bpo-17960.

Mark,

Issue bpo-17960 ("Clarify the required behaviour of locals()") does not seem to be relevant here. I think you meant to refer to a changeset, not issue number. If so please use hash number such as d877d7f3b679.

As far as I can tell, the original report was about a test failing due to a system-dependent behavior of time.asctime(). However, since changeset 1e62a0cee092 (see issue bpo-8013), we no longer call system asctime. I believe the test disabled in 1a0bfc26af57 can now be restored.

Sorry should have been bpo-17690.

We still have the following in Lib/test/test_time.py:

        # Issue python/cpython#57521: it may return wrong value for year < TIME_MINYEAR + 1900
        # Skip the value test, but check that no error is raised
        self.yearstr(TIME_MINYEAR)

I reviewed the current time.asctime() code and it does look like it invokes undefined behavior for extremely large negative years.

The problem is that in C struct tm, year is stored as year - 1900 and for year < -2147481748 (= -2**31 + 1900) we trigger an overflow of a signed integer.

Can someone confirm that on AMD64 FreeBSD subtracting 1900 from -2147483648 and then adding it back does not give -2147483648?

Attached patch eliminates undefined behavior, but I am not sure fixing this is worth the trouble.

If you enable GCC’s -ftrapv option, the subtraction overflow triggers an abort. Alexander’s patch works around the problem for asctime(), but the problem still exists in other cases, such as:

>>> time.mktime((-2**31 + 1899, *(0,) * 8))
Aborted (core dumped)
[Exit 134]

Attaching a version of the patch without the conflicting whitespace changes.

Why does Python even need to support such extreme time values? It would seem much simpler to raise an exception.

New changeset 76be0ff by Gregory P. Smith in branch 'master':
bpo-13312: Avoid int underflow in time year. (GH-8912)
76be0ff

New changeset d5f017b by Miss Islington (bot) in branch '3.7':
bpo-13312: Avoid int underflow in time year. (GH-8912)
d5f017b

New changeset c47acc2 by Miss Islington (bot) in branch '3.6':
bpo-13312: Avoid int underflow in time year. (GH-8912)
c47acc2

OverflowError is now raised for negative values that would trigger a problem and the unittest has been updated to test this.

Note for myself: Python 2.7 is not affected by this bug because it doesn't accept year < 1900.