[Datetime-SIG] Drop datetime's offset restrictions?

[Tim Peters]

I propose dropping datetime's offset restrictions.  Currently,
datetime's .dst() and .utcoffset() raise an exception if their tzinfo
implementations return a timedelta representing anything other than a
whole number of minutes in (-1440, 1440) (i.e., magnitude strictly
less than a day).

The intent was to help catch programmer errors, but I'm not sure it's
ever caught one.  The "inspiration" came from staring at various C
time-and-date libraries at the time, and puzzling over lines like:

#define MWEEK 12

Huh?  12 what?  Seconds, minutes, time zones?  Is "M" short for
million, or milli, or modern, or what?

But in Python the timedelta constructor is typically used with keyword
arguments, making the intended unit blindingly obvious.  If you intend
1 hour, you say hours=1; etc.

So enforcing restrictions burns time and doc space without clear
benefit.  The rest of the code doesn't care.  Any representable
duration should work fine.

The Olson ("zoneinfo") database contains historical offsets needing
1-second resolution, which is the smallest unit it can represent.
That's a compromise too; e.g., here from its "THEORY" file:

    Sometimes historical timekeeping was specified more precisely
    than what the tz database can handle.  For example, from 1909 to
    1937 Netherlands clocks were legally UT+00:19:32.13, but the tz
    database cannot represent the fractional second.

But Python can:

>>> print(timedelta(minutes=19, seconds=32, milliseconds=130))
0:19:32.130000

I don't really care about supporting such silliness, but neither do I
want to frustrate someone who does.

Whaddya think?  Continue nagging people for no reason at all, or let
freedom bloom? ;-)