Tests: OverflowError on i686 and mips64el

[htgoebel]

test_date_time_this_period and test_date_time_this_period_with_tzinfo fail on i686 and mips64el. For details please see

• http://hydra.gnu.org/build/1542859 (i686)
• http://hydra.gnu.org/build/1542830 (mips64el)
• http://hydra.gnu.org/build/1542764 (x86_64, passing)

ERROR: test_date_time_this_period (faker.tests.FactoryTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/tests/__init__.py", line 376, in test_date_time_this_period
    self.assertTrue(self._datetime_to_time(provider.date_time_this_century(before_now=False, after_now=True)) >= self._datetime_to_time(datetime.datetime.now()))
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 387, in date_time_this_century
    return cls.date_time_between_dates(now, next_century_start, tzinfo)
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 365, in date_time_between_dates
    datetime_to_timestamp(datetime_end),
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 22, in datetime_to_timestamp
    return mktime(dt.timetuple())
OverflowError: mktime argument out of range

======================================================================
ERROR: test_date_time_this_period_with_tzinfo (faker.tests.FactoryTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/tests/__init__.py", line 405, in test_date_time_this_period_with_tzinfo
    provider.date_time_this_century(before_now=False, after_now=True, tzinfo=utc) >= datetime.datetime.now()
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 387, in date_time_this_century
    return cls.date_time_between_dates(now, next_century_start, tzinfo)
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 365, in date_time_between_dates
    datetime_to_timestamp(datetime_end),
  File "/tmp/guix-build-python-fake-factory-0.7.2.drv-0/fake-factory-0.7.2/faker/providers/date_time/__init__.py", line 21, in datetime_to_timestamp
    dt = dt.astimezone(tzlocal())
  File "/gnu/store/3wppcdw10k68aiw2x1r0x2m9zd10lg63-python-dateutil-2.5.2/lib/python3.4/site-packages/python_dateutil-2.5.2-py3.4.egg/dateutil/tz/tz.py", line 99, in utcoffset
    if self._isdst(dt):
  File "/gnu/store/3wppcdw10k68aiw2x1r0x2m9zd10lg63-python-dateutil-2.5.2/lib/python3.4/site-packages/python_dateutil-2.5.2-py3.4.egg/dateutil/tz/tz.py", line 143, in _isdst
    return time.localtime(timestamp+time.timezone).tm_isdst
OverflowError: timestamp out of range for platform time_t

[NathanWailes]

See:
http://stackoverflow.com/questions/2518706/python-mktime-overflow-error
https://docs.python.org/2/library/time.html#time.mktime
"The earliest date for which it can generate a time is platform-dependent."

[deep-42-thought]

So can you please disable the respective tests on i686?

[htgoebel]

Disabling tests is a bad idea since it covers problems.

The bug is caused by this line creating a value which not accepted at these platforms:

next_century_start = datetime(this_century_start.year + 100, 1, 1, tzinfo=tzinfo)

The same problem theoretically exists in date_time_this_decade() with next_decade() for the case the tests are run near the end of the supported year-range.

The solution is to use

next_century_start = datetime(min(this_century_start.year + 100, datetime.date.max.year),
                              1, 1, tzinfo=tzinfo)

Same for date_time_this_decade().

Maybe you also want to issue a warning if this case occurs.

[htgoebel]

datetime.MAXYEAR is the same as datetime.date.max.year. You may prefer this

[htgoebel]

Oh, well, this might analysis might be wrong: MAXYEAR is defined to be 9999.

[fcurella]

I can switch behavior for 32bit system to something like solution suggested by @htgoebel. What should the max year be on 32bit systems?

[htgoebel]

Depending this on 32-bit is dangerous and wrong: mips64el is 64-bit.

I'm afraid you need to have a deeper look into your code to find out where you query the boundary.