Re: [Python-modules-team] Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t
On Mon, 30 Jan 2017 at 20:31:06 +1100, Brian May wrote:
> > File "faker/providers/date_time/__init__.py", line 403, in date_time_this_century
> > return cls.date_time_between_dates(now, next_century_start, tzinfo)
> > File "faker/providers/date_time/__init__.py", line 381, in date_time_between_dates
> > datetime_to_timestamp(datetime_end),
> > File "faker/providers/date_time/__init__.py", line 21, in datetime_to_timestamp
> > dt = dt.astimezone(tzlocal())
> > File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 99, in utcoffset
> > if self._isdst(dt):
> > File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 143, in _isdst
> > return time.localtime(timestamp+time.timezone).tm_isdst
> > ValueError: timestamp out of range for platform time_t
It looks as though this module is doing date/time computations with libc
time_t (signed integer seconds since 1970-01-01 00:00 UTC).
On older 32-bit ABIs like i386, time_t is just not large enough to
represent dates after 2038 - there are not enough bits. Anything needing
to compute dates outside the range 1970 to 2038 in a portable way needs
to use something that is not time_t. There is no way around that.
next_century_start sounds suspiciously like it might be 2100-01-01,
which is too late to be representable in 32-bit time_t.
If this particular functionality is not release-critically important,
then its test might need to be skipped on architectures where
time.localtime(2**32) would raise an exception, with a note in its
documentation that it only works on platforms with 64-bit time_t
(that's 64-bit platforms, plus newer 32-bit ABIs like x32).
> (not sure but suspect it might be too late for stretch)
For what it's worth, I had a brief look at this package during the bug
squashing party this weekend, and de-prioritized it on the basis that it
has never been in a stable release, removing faker and factory-boy from
testing would not break any other dependencies or build-dependencies,
and they appear to be development tools rather than user-facing
functionality. Obviously you're welcome to fix it if it's useful to
you, but I don't think it is necessarily a top priority to have in the
stretch release, so I spent my time fixing different RC bugs instead.
S
Reply to: