Opened 3 years ago

Closed 3 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 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 3 years ago by Bradley Ayers <bradley.ayers@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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

comment:2 Changed 3 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 3 years ago by aaugustin

  • Description modified (diff)

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

comment:5 Changed 3 years ago by jezdez

  • Component changed from Core (Other) to Internationalization

comment:6 Changed 3 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