Opened 5 years ago

Closed 5 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 https://code.djangoproject.com/changeset/17642

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 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:1 Changed 5 years ago by Bradley Ayers <bradley.ayers@…>

Correction:

django.template.defaultfilters import localtime

…should have been:

from django.templatetags.tz 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 5 years ago by Aymeric Augustin

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