Opened 13 years ago
Closed 13 years ago
#17992 closed New feature (fixed)
Public API for localtime
Reported by: | Owned by: | Aymeric Augustin | |
---|---|---|---|
Component: | Internationalization | Version: | 1.4 |
Severity: | Normal | Keywords: | timezone localtime |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I think there should be a public API for converting timezone aware datetime objects to current timezone versions. This actually existed in django.utils.timezone as localtime, but was made private and removed from the documentation in https://code.djangoproject.com/changeset/17642
The current options for converting a datetime to the current timezone are:
- Use Python's datetime.astimezone in conjunction with django.utils.timezone helpers:
from django.utils import timezone local = dt.astimezone(timezone.get_current_timezone())
- Use the public API for the localtime template filter via the privatish module django.template.defaultfilters:
from django.templatetags.tz import localtime local = localtime(dt)
While (2) is much cleaner, I'd argue it's dirty to import from defaultfilters.
I propose re-publicising django.utils.timezone.localtime as a public API.
My use-case is generating PDFs that have datetimes in their content.
Change History (6)
comment:2 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
I made django.utils.timezone.localtime
private because it contains some template-specific code.
I agree it would make sense to expose a similar function, without the template-specific bits, for general use.
This function actually has two variants: "default local time" or "current local time". As long as you don't have a timezone switcher for your end users, there's no difference between these. However, we should take this into account while extending the public API.
comment:3 by , 13 years ago
Description: | modified (diff) |
---|
comment:4 by , 13 years ago
Owner: | changed from | to
---|
Anssi suggests that localtime
should use the current time zone, which can be explicitly changed if necessary.
datetime_in_current_tz = localtime(datetime_in_any_tz) with timezone.override(get_default_timezone()): datetime_in_default_tz = localtime(datetime_in_any_tz) with timezone.override(other_tz): datetime_in_other_tz = localtime(datetime_in_any_tz)
The alternative is to add an optional argument:
datetime_in_current_tz = localtime(datetime_in_any_tz) datetime_in_default_tz = localtime(datetime_in_any_tz, get_default_timezone()) datetime_in_other_tz = localtime(datetime_in_any_tz, other_tz)
I have a slight preference for the second version, mostly because it is shorter.
No better name than localtime
came up during the IRC discussion.
comment:5 by , 13 years ago
Component: | Core (Other) → Internationalization |
---|
comment:6 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
FIxed in 3e8b40f479a02e0f8c40ef3c7dae740082478b89.
Correction:
…should have been:
EDIT(aaugustin): I made this change in the summary.