ANN: pytz-2004b World timezone library

[Tim Peters]

[Tim Peters]
>> ...As designed and documented, datetime module arithmetic within a
>> single timezone is "naive" arithmetic, ...
>>  The intended way to trip over daylight quirks *when
>> desired* is to convert to UTC first, do arithmetic in UTC, then
>> convert back from UTC.
 
[Stuart Bishop]
> ...
> Although it would be a very minor and benign modification - just
> need to call the localize method (if it exists) in the datetime
> constructor and the normalize method (if it exists) before returning
> the result of date arithmetic...

If you want to pursue it, submit a patch.  I expect, but don't know,
that Guido would be opposed, because "naive time" is thought to be a
feature in this module.  I suspect you think of it as a lazy
compromise (or something of that nature), in which case there's a
clash in design philosophies.

...
> Does that mean I get to bitch about the datetime.strftime insisting
> offsets are whole minutes because it can't be bothered rounding them
> off itself ;)

Sorry, I have no idea what this one is about.  If you're talking about
the strftime %z format code (seems likely, but I'm guessing), all
spellings of strftime in Python are wrappers around the platform C
strftime() function, and ANSI C restricts %z to whole minutes.  The
datetime.tzinfo utcoffset() method is also, by design, required to
return a whole number of minutes (in -1439 through 1439 inclusive). 
The datetime design was conducted on a public Wiki (a Zope
"fishbowl"), and primarily reflects the requirements of the community
that paid for its development -- nobody there wanted fractional-minute
offsets (in fact, I don't recall anyone mentioning them before).

None of that means you shouldn't bitch, though <wink>.