This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mibanescu
Recipients mibanescu
Date 2009-07-13.17:33:42
SpamBayes Score 1.4113325e-05
Marked as misclassified No
Message-id <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
In-reply-to
Content
If one changes from one timezone to another within the same python
process, and if one tries to parse a time string that includes the
timezone, the library malfunctions.

See attached script for a reproducer.

The problem is that, even though time.tzset() is called, the LocaleTime
persisted in the TimeRE global is not reset. In my example, the EDT
timezone name, compiled from the previous TZ variable, is not valid
anymore in the 'Pacific/Fiji' timezone.

To witness the behavior, run the attached script with no arguments. It
will parse the time in the America/New_York timezone just fine.

Then run it with an argument (like python ttime.py 1). It will first
prime the _strptime cache in the Pacific/Fiji timezone, then attempt to
parse the same time string in the America/New_York timezone.

Finally, you can change the "if 0" to "if 1" for working around the problem.

This has been verified in 2.4.4 and 2.6.1 (did not have a chance to
verify it against python 2.6.2 yet).
History
Date User Action Args
2009-07-13 17:33:46mibanescusetrecipients: + mibanescu
2009-07-13 17:33:45mibanescusetmessageid: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
2009-07-13 17:33:43mibanesculinkissue6478 messages
2009-07-13 17:33:43mibanescucreate