ANN: pytz-2004b World timezone library

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 22/07/2004, at 2:28 AM, Tim Peters wrote:

> [Stuart Bishop]
>> ...
>> Note that if you perform date arithmetic on local times that cross DST
>> boundaries, the results may be in an incorrect timezone (ie. subtract
>> 1 minute from 2002-10-27 1:00 EST and you get 2002-10-27 0:59 EST
>> instead of the correct 2002-10-27 1:59 EDT). This cannot be resolved 
>> without
>> modifying the Python datetime implementation.
>
> That's unlikely to happen.  As designed and documented, datetime
> module arithmetic within a single timezone is "naive" arithmetic,
> based on Guido's belief that most users most of the time find that
> most useful.  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.

Ignore me - I'm just buck passing :D

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

>> However, these tzinfo classes provide a normalize() method which 
>> allows
>> you to correct these values.
>
> That's another idea <wink>.
>
> Thank you for doing this!  I know it's a messy and mostly thankless 
> task.

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

- --  
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBBB2YAfqZj7rGN0oRAujmAKCIrZ/OqKURpG/OVsw2SZUMBGGeIQCgid9q
pvp2+EDjpVcZf12NGkCdATw=
=oXC8
-----END PGP SIGNATURE-----