Opened 13 years ago

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

Correction:

django.template.defaultfilters import localtime

…should have been:

from django.templatetags.tz import localtime
Version 0, edited 13 years ago by Bradley Ayers <bradley.ayers@…> (next)

comment:2 by Aymeric Augustin, 13 years ago

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 by Aymeric Augustin, 13 years ago

Description: modified (diff)

comment:4 by Aymeric Augustin, 13 years ago

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 13 years ago by Aymeric Augustin (previous) (diff)

comment:5 by Jannis Leidel, 13 years ago

Component: Core (Other)Internationalization

comment:6 by Aymeric Augustin, 13 years ago

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