Opened 5 years ago

Closed 4 years ago

#17992 closed New feature (fixed)

Public API for localtime

Reported by: Bradley Ayers <bradley.ayers@…> 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 Aymeric Augustin)

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

The current options for converting a datetime to the current timezone are:

  1. Use Python's datetime.astimezone in conjunction with django.utils.timezone helpers:
from django.utils import timezone
local = dt.astimezone(timezone.get_current_timezone())
  1. Use the public API for the localtime template filter via the privatish module django.template.defaultfilters:
from 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:1 Changed 5 years ago by Bradley Ayers <bradley.ayers@…>

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset


django.template.defaultfilters import localtime

…should have been:

from import localtime

EDIT(aaugustin): I made this change in the summary.

Last edited 5 years ago by Aymeric Augustin (previous) (diff)

comment:2 Changed 5 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted

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 Changed 5 years ago by Aymeric Augustin

Description: modified (diff)

comment:4 Changed 5 years ago by Aymeric Augustin

Owner: changed from nobody to Aymeric Augustin

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.

Last edited 5 years ago by Aymeric Augustin (previous) (diff)

comment:5 Changed 5 years ago by Jannis Leidel

Component: Core (Other)Internationalization

comment:6 Changed 4 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top