ANN: pytz-2004b World timezone library
stuart at stuartbishop.net
Sun Jul 25 22:52:39 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
>> you to correct these values.
> That's another idea <wink>.
> Thank you for doing this! I know it's a messy and mostly thankless
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-list