On Wed, Mar 5, 2014 at 5:53 PM, Tim Peters <tim.peters@gmail.com> wrote:
That's there because `utcoffset()` is defined to return minutes.  

It returns either minutes or a timedelta:

datetime.utcoffset()
If tzinfo is None, returns None, else returns self.tzinfo.utcoffset(self), and raises an exception if the latter doesn’t return None, or a timedelta object representing a whole number of minutes with magnitude less than one day.

tzinfo.utcoffset(self, dt)

Return offset of local time from UTC, in minutes east of UTC. If local time is west of UTC, this should be negative. Note that this is intended to be the total offset from UTC; for example, if atzinfo object represents both time zone and DST adjustments, utcoffset() should return their sum. If the UTC offset isn’t known, return None. Else the value returned must be a timedeltaobject specifying a whole number of minutes in the range -1439 to 1439 inclusive (1440 = 24*60; the magnitude of the offset must be less than one day). 


A
rule is needed to specify how the naive time object and `utcoffset()`
interact to define the result.

Not sure why you attach 'naive' to time. Time objects carry units with them, unlike integers. I would say 'naive time value' in reference to an integer.

Combining a time and an integer can be done by converting the time to minutes (which is a bit confusing since in most contexts in this class, minutes values are integers) or it can be done by interpreting the integer utcoffset result as minutes (as it is documented).

 
> Perhaps a reasonable improvement would be to change this to:
>
> a time object is considered to be true unless it represents exactly midnight
> local time,

The above part is the key part of my suggested improvement. Reading the current documentation, the fact that it means midnight local time is falsey is not obvious. 


--- Bruce
Learn how hackers think: http://j.mp/gruyere-security