#22625 closed Bug (fixed)
Installing pytz breaks code already using django's timezone module
Reported by: | Owned by: | Aymeric Augustin | |
---|---|---|---|
Component: | Utilities | Version: | 1.6 |
Severity: | Normal | Keywords: | pytz, timezone |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
pytz is an optional module for Django, used in django.utils.timezone (and possibly elsewhere). The documentation recommends that pytz is installed, but it's not a requirement.
The bug is that after installing pytz, methods in django's timezone module do not present the same interface as before installation. Installing an optional module should not adjust the interface presented.
The following code works differently before and after installation of pytz:
from django.utils import timezone now = timezone.now() timezone.make_aware(now, timezone.utc())
Before installing pytz, timezone.make_aware essentially does nothing (the variable is already timezone aware). After installing pytz, timezone.make_aware makes a call to pytz which raises 'ValueError: Not naive datetime (tzinfo is already set)', and causes everything to break.
While I discovered this in django 1.5, I've also been able to replicate the bug in django 1.6, so I am filing the bug report under that.
Change History (7)
comment:1 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 10 years ago
comment:4 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
There are two possible semantics when make_aware receives an aware datetime (or make_naive receives a naive datetime):
Since Django uses the first one when pytz is installed, and the docs recommend to install pytz, it makes sense to enforce that behavior.