Opened 4 years ago

Closed 4 years ago

#17992 closed New feature (fixed)

Public API for localtime

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

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 4 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 4 years ago by aaugustin (previous) (diff)

comment:2 Changed 4 years ago by aaugustin

  • Triage Stage changed from Unreviewed to 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 Changed 4 years ago by aaugustin

  • Description modified (diff)

comment:4 Changed 4 years ago by aaugustin

  • Owner changed from nobody to aaugustin

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 4 years ago by aaugustin (previous) (diff)

comment:5 Changed 4 years ago by jezdez

  • Component changed from Core (Other) to Internationalization

comment:6 Changed 4 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.
Back to Top