Discovered this bug in #565 in the test for Monrovia. I'm guessing that the problem is that before Python 3.6-ish, datetime didn't support this at all:

>>> from dateutil import tz
>>> from datetime import *
>>> tzi = tz.tzoffset(None, timedelta(hours=12, seconds=30))
>>> datetime(2000, 1, 1, tzinfo=tzi)
datetime.datetime(2000, 1, 1, 0, 0, tzinfo=tzoffset(None, 43230))
>>> datetime(2000, 1, 1, tzinfo=tzi).utcoffset()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tzinfo.utcoffset() must return a whole number of minutes

This should definitely be fixed in all versions of Python that support non-integer offsets, and the main question is what to do in the other cases. The options we have are:

1. Continue the current behavior of silently truncating to the nearest minute
2. Truncate the offset and add a warning in the constructor when a timezone with a non-integer number of minutes is constructed on a platform that doesn't support it.
3. Truncate the offset and add a warning in utcoffset or something when a platform doesn't support it.
4. Don't truncate at all and let .utcoffset() throw errors on platforms that don't support the non-truncated version.

I suspect that this affects a vanishingly small number of people, so my preferred solution is the one that has minimal impact on those people who are using timezones with integer number of minute offsets and people using a recent version of Python. I imagine that rules out a check in utcoffset. The lowest-cost thing to do is the fourth one, but that's the least friendly way. I'm thinking 2 is the right way to go.

Ideally we'll merge #580 and use that framework to distinguish between the different approaches.

This issue is currently blocking the merge of #565.