ANN: pytz-2004b World timezone library

Stuart Bishop stuart at
Mon Jul 26 13:55:30 CEST 2004

Hash: SHA1

On 26/07/2004, at 12:39 AM, Tim Peters wrote:

>> 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).

At the moment everything seems to work just dandy with
fractional-minute utcoffsets, until it is time to convert
the result into a string. At this point a ValueError is raised
instead of rounding. So I have to return rounded offsets, just
like the documentation tells me to do. The end result is that
calculations done with datetime might be +/- 30 seconds the
calculations done using, say, the systems libc time libraries
(tzset etc.). The sort of stuff only test suites and the
anal retentive care about :-)

> 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).

I never realized how common they used to be until I saw how much of
my test suite was breaking :-) These crazy people used to think noon
was when the sun was at its highest point or something.

I know... I know... submit a patch. Thankfully I have until 2.5 alpha
to overcome my distaste of 'icky C code :-)

- --  
Stuart Bishop <stuart at>
Version: GnuPG v1.2.3 (Darwin)


More information about the Python-list mailing list