<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Time zones — Django 1.4.5 documentation</title>
<link rel="stylesheet" href="../../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../../',
VERSION: '1.4.5',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../../_static/jquery.js"></script>
<script type="text/javascript" src="../../_static/underscore.js"></script>
<script type="text/javascript" src="../../_static/doctools.js"></script>
<link rel="top" title="Django 1.4.5 documentation" href="../../index.html" />
<link rel="up" title="Internationalization and localization" href="index.html" />
<link rel="next" title="Logging" href="../logging.html" />
<link rel="prev" title="Format localization" href="formatting.html" />
<script type="text/javascript" src="../../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../../index.html">Django 1.4.5 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../../index.html">Home</a> |
<a title="Table of contents" href="../../contents.html">Table of contents</a> |
<a title="Global index" href="../../genindex.html">Index</a> |
<a title="Module index" href="../../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="formatting.html" title="Format localization">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="../logging.html" title="Logging">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="topics-i18n-timezones">
<div class="section" id="s-time-zones">
<span id="s-id1"></span><span id="time-zones"></span><span id="id1"></span><h1>Time zones<a class="headerlink" href="#time-zones" title="Permalink to this headline">¶</a></h1>
<div class="versionadded">
<span class="title">New in Django 1.4:</span> <a class="reference internal" href="../../releases/1.4.html"><em>Please see the release notes</em></a></div>
<div class="section" id="s-overview">
<span id="s-time-zones-overview"></span><span id="overview"></span><span id="time-zones-overview"></span><h2>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
<p>When support for time zones is enabled, Django stores date and time
information in UTC in the database, uses time-zone-aware datetime objects
internally, and translates them to the end user’s time zone in templates and
forms.</p>
<p>This is handy if your users live in more than one time zone and you want to
display date and time information according to each user’s wall clock.</p>
<p>Even if your Web site is available in only one time zone, it’s still good
practice to store data in UTC in your database. One main reason is Daylight
Saving Time (DST). Many countries have a system of DST, where clocks are moved
forward in spring and backward in autumn. If you’re working in local time,
you’re likely to encounter errors twice a year, when the transitions happen.
(The <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> documentation discusses <a class="reference external" href="http://pytz.sourceforge.net/#problems-with-localtime">these issues</a> in greater detail.) This
probably doesn’t matter for your blog, but it’s a problem if you over-bill or
under-bill your customers by one hour, twice a year, every year. The solution
to this problem is to use UTC in the code and use local time only when
interacting with end users.</p>
<p>Time zone support is disabled by default. To enable it, set <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span>
<span class="pre">True</span></tt></a> in your settings file. Installing <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> is highly recommended,
but not mandatory. It’s as simple as:</p>
<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>sudo pip install pytz
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The default <tt class="file docutils literal"><span class="pre">settings.py</span></tt> file created by <a class="reference internal" href="../../ref/django-admin.html#django-admin-startproject"><tt class="xref std std-djadmin docutils literal"><span class="pre">django-admin.py</span>
<span class="pre">startproject</span></tt></a> includes <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">True</span></tt></a>
for convenience.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">There is also an independent but related <a class="reference internal" href="../../ref/settings.html#std:setting-USE_L10N"><tt class="xref std std-setting docutils literal"><span class="pre">USE_L10N</span></tt></a> setting that
controls whether Django should activate format localization. See
<a class="reference internal" href="formatting.html"><em>Format localization</em></a> for more details.</p>
</div>
<p>If you’re wrestling with a particular problem, start with the <a class="reference internal" href="#time-zones-faq"><em>time zone
FAQ</em></a>.</p>
</div>
<div class="section" id="s-concepts">
<span id="concepts"></span><h2>Concepts<a class="headerlink" href="#concepts" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-naive-and-aware-datetime-objects">
<span id="naive-and-aware-datetime-objects"></span><h3>Naive and aware datetime objects<a class="headerlink" href="#naive-and-aware-datetime-objects" title="Permalink to this headline">¶</a></h3>
<p>Python’s <tt class="xref py py-class docutils literal"><span class="pre">datetime.datetime</span></tt> objects have a <tt class="docutils literal"><span class="pre">tzinfo</span></tt> attribute that
can be used to store time zone information, represented as an instance of a
subclass of <tt class="xref py py-class docutils literal"><span class="pre">datetime.tzinfo</span></tt>. When this attribute is set and describes
an offset, a datetime object is <strong>aware</strong>. Otherwise, it’s <strong>naive</strong>.</p>
<p>You can use <a class="reference internal" href="../../ref/utils.html#django.utils.timezone.is_aware" title="django.utils.timezone.is_aware"><tt class="xref py py-func docutils literal"><span class="pre">is_aware()</span></tt></a> and
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.is_naive" title="django.utils.timezone.is_naive"><tt class="xref py py-func docutils literal"><span class="pre">is_naive()</span></tt></a> to determine whether datetimes are
aware or naive.</p>
<p>When time zone support is disabled, Django uses naive datetime objects in local
time. This is simple and sufficient for many use cases. In this mode, to obtain
the current time, you would write:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">datetime</span>
<span class="n">now</span> <span class="o">=</span> <span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="o">.</span><span class="n">now</span><span class="p">()</span>
</pre></div>
</div>
<p>When time zone support is enabled, Django uses time-zone-aware datetime
objects. If your code creates datetime objects, they should be aware too. In
this mode, the example above becomes:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">datetime</span>
<span class="kn">from</span> <span class="nn">django.utils.timezone</span> <span class="kn">import</span> <span class="n">utc</span>
<span class="n">now</span> <span class="o">=</span> <span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="o">.</span><span class="n">utcnow</span><span class="p">()</span><span class="o">.</span><span class="n">replace</span><span class="p">(</span><span class="n">tzinfo</span><span class="o">=</span><span class="n">utc</span><span class="p">)</span>
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><a class="reference internal" href="../../ref/utils.html#module-django.utils.timezone" title="django.utils.timezone: Timezone support."><tt class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></tt></a> provides a
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.now" title="django.utils.timezone.now"><tt class="xref py py-func docutils literal"><span class="pre">now()</span></tt></a> function that returns a naive or
aware datetime object according to the value of <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a>.</p>
</div>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Dealing with aware datetime objects isn’t always intuitive. For instance,
the <tt class="docutils literal"><span class="pre">tzinfo</span></tt> argument of the standard datetime constructor doesn’t work
reliably for time zones with DST. Using UTC is generally safe; if you’re
using other time zones, you should review the <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> documentation
carefully.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>Python’s <tt class="xref py py-class docutils literal"><span class="pre">datetime.time</span></tt> objects also feature a <tt class="docutils literal"><span class="pre">tzinfo</span></tt>
attribute, and PostgreSQL has a matching <tt class="docutils literal"><span class="pre">time</span> <span class="pre">with</span> <span class="pre">time</span> <span class="pre">zone</span></tt> type.
However, as PostgreSQL’s docs put it, this type “exhibits properties which
lead to questionable usefulness”.</p>
<p class="last">Django only supports naive time objects and will raise an exception if you
attempt to save an aware time object.</p>
</div>
</div>
<div class="section" id="s-interpretation-of-naive-datetime-objects">
<span id="s-naive-datetime-objects"></span><span id="interpretation-of-naive-datetime-objects"></span><span id="naive-datetime-objects"></span><h3>Interpretation of naive datetime objects<a class="headerlink" href="#interpretation-of-naive-datetime-objects" title="Permalink to this headline">¶</a></h3>
<p>When <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a> is <tt class="docutils literal"><span class="pre">True</span></tt>, Django still accepts naive datetime
objects, in order to preserve backwards-compatibility. When the database layer
receives one, it attempts to make it aware by interpreting it in the
<a class="reference internal" href="#default-current-time-zone"><em>default time zone</em></a> and raises a warning.</p>
<p>Unfortunately, during DST transitions, some datetimes don’t exist or are
ambiguous. In such situations, <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> raises an exception. Other
<tt class="xref py py-class docutils literal"><span class="pre">tzinfo</span></tt> implementations, such as the local time zone used as
a fallback when <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> isn’t installed, may raise an exception or return
inaccurate results. That’s why you should always create aware datetime objects
when time zone support is enabled.</p>
<p>In practice, this is rarely an issue. Django gives you aware datetime objects
in the models and forms, and most often, new datetime objects are created from
existing ones through <tt class="xref py py-class docutils literal"><span class="pre">timedelta</span></tt> arithmetic. The only
datetime that’s often created in application code is the current time, and
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.now" title="django.utils.timezone.now"><tt class="xref py py-func docutils literal"><span class="pre">timezone.now()</span></tt></a> automatically does the
right thing.</p>
</div>
<div class="section" id="s-default-time-zone-and-current-time-zone">
<span id="s-default-current-time-zone"></span><span id="default-time-zone-and-current-time-zone"></span><span id="default-current-time-zone"></span><h3>Default time zone and current time zone<a class="headerlink" href="#default-time-zone-and-current-time-zone" title="Permalink to this headline">¶</a></h3>
<p>The <strong>default time zone</strong> is the time zone defined by the <a class="reference internal" href="../../ref/settings.html#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a>
setting.</p>
<p>The <strong>current time zone</strong> is the time zone that’s used for rendering.</p>
<p>You should set the current time zone to the end user’s actual time zone with
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.activate" title="django.utils.timezone.activate"><tt class="xref py py-func docutils literal"><span class="pre">activate()</span></tt></a>. Otherwise, the default time zone is
used.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>As explained in the documentation of <a class="reference internal" href="../../ref/settings.html#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a>, Django sets
environment variables so that its process runs in the default time zone.
This happens regardless of the value of <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a> and of the
current time zone.</p>
<p class="last">When <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a> is <tt class="docutils literal"><span class="pre">True</span></tt>, this is useful to preserve
backwards-compatibility with applications that still rely on local time.
However, <a class="reference internal" href="#naive-datetime-objects"><em>as explained above</em></a>, this isn’t
entirely reliable, and you should always work with aware datetimes in UTC
in your own code. For instance, use
<tt class="xref py py-meth docutils literal"><span class="pre">utcfromtimestamp()</span></tt> instead of
<tt class="xref py py-meth docutils literal"><span class="pre">fromtimestamp()</span></tt> – and don’t forget to set
<tt class="docutils literal"><span class="pre">tzinfo</span></tt> to <a class="reference internal" href="../../ref/utils.html#django.utils.timezone.utc" title="django.utils.timezone.utc"><tt class="xref py py-data docutils literal"><span class="pre">utc</span></tt></a>.</p>
</div>
</div>
<div class="section" id="s-selecting-the-current-time-zone">
<span id="selecting-the-current-time-zone"></span><h3>Selecting the current time zone<a class="headerlink" href="#selecting-the-current-time-zone" title="Permalink to this headline">¶</a></h3>
<p>The current time zone is the equivalent of the current <a class="reference internal" href="index.html#term-locale-name"><em class="xref std std-term">locale</em></a> for translations. However, there’s no equivalent of the
<tt class="docutils literal"><span class="pre">Accept-Language</span></tt> HTTP header that Django could use to determine the user’s
time zone automatically. Instead, Django provides <a class="reference internal" href="../../ref/utils.html#time-zone-selection-functions"><em>time zone selection
functions</em></a>. Use them to build the time zone
selection logic that makes sense for you.</p>
<p>Most Web sites that care about time zones just ask users in which time zone they
live and store this information in the user’s profile. For anonymous users,
they use the time zone of their primary audience or UTC. <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> provides
<a class="reference external" href="http://pytz.sourceforge.net/#helpers">helpers</a>, like a list of time zones per country, that you can use to pre-select
the most likely choices.</p>
<p>Here’s an example that stores the current timezone in the session. (It skips
error handling entirely for the sake of simplicity.)</p>
<p>Add the following middleware to <a class="reference internal" href="../../ref/settings.html#std:setting-MIDDLEWARE_CLASSES"><tt class="xref std std-setting docutils literal"><span class="pre">MIDDLEWARE_CLASSES</span></tt></a>:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
<span class="k">class</span> <span class="nc">TimezoneMiddleware</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">process_request</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">):</span>
<span class="n">tz</span> <span class="o">=</span> <span class="n">request</span><span class="o">.</span><span class="n">session</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="s">'django_timezone'</span><span class="p">)</span>
<span class="k">if</span> <span class="n">tz</span><span class="p">:</span>
<span class="n">timezone</span><span class="o">.</span><span class="n">activate</span><span class="p">(</span><span class="n">tz</span><span class="p">)</span>
</pre></div>
</div>
<p>Create a view that can set the current timezone:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">pytz</span>
<span class="kn">from</span> <span class="nn">django.shortcuts</span> <span class="kn">import</span> <span class="n">redirect</span><span class="p">,</span> <span class="n">render</span>
<span class="k">def</span> <span class="nf">set_timezone</span><span class="p">(</span><span class="n">request</span><span class="p">):</span>
<span class="k">if</span> <span class="n">request</span><span class="o">.</span><span class="n">method</span> <span class="o">==</span> <span class="s">'POST'</span><span class="p">:</span>
<span class="n">request</span><span class="o">.</span><span class="n">session</span><span class="p">[</span><span class="n">session_key</span><span class="p">]</span> <span class="o">=</span> <span class="n">pytz</span><span class="o">.</span><span class="n">timezone</span><span class="p">(</span><span class="n">request</span><span class="o">.</span><span class="n">POST</span><span class="p">[</span><span class="s">'timezone'</span><span class="p">])</span>
<span class="k">return</span> <span class="n">redirect</span><span class="p">(</span><span class="s">'/'</span><span class="p">)</span>
<span class="k">else</span><span class="p">:</span>
<span class="k">return</span> <span class="n">render</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="s">'template.html'</span><span class="p">,</span> <span class="p">{</span><span class="s">'timezones'</span><span class="p">:</span> <span class="n">pytz</span><span class="o">.</span><span class="n">common_timezones</span><span class="p">})</span>
</pre></div>
</div>
<p>Include a form in <tt class="docutils literal"><span class="pre">template.html</span></tt> that will <tt class="docutils literal"><span class="pre">POST</span></tt> to this view:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="cp">{%</span> <span class="k">load</span> <span class="nv">tz</span> <span class="cp">%}{%</span> <span class="k">load</span> <span class="nv">url</span> <span class="nv">from</span> <span class="nv">future</span> <span class="cp">%}</span>
<span class="nt"><form</span> <span class="na">action=</span><span class="s">"</span><span class="cp">{%</span> <span class="k">url</span> <span class="s1">'set_timezone'</span> <span class="cp">%}</span><span class="s">"</span> <span class="na">method=</span><span class="s">"POST"</span><span class="nt">></span>
<span class="cp">{%</span> <span class="k">csrf_token</span> <span class="cp">%}</span>
<span class="nt"><label</span> <span class="na">for=</span><span class="s">"timezone"</span><span class="nt">></span>Time zone:<span class="nt"></label></span>
<span class="nt"><select</span> <span class="na">name=</span><span class="s">"timezone"</span><span class="nt">></span>
<span class="cp">{%</span> <span class="k">for</span> <span class="nv">tz</span> <span class="k">in</span> <span class="nv">timezones</span> <span class="cp">%}</span>
<span class="nt"><option</span> <span class="na">value=</span><span class="s">"</span><span class="cp">{{</span> <span class="nv">tz</span> <span class="cp">}}</span><span class="s">"</span><span class="cp">{%</span> <span class="k">if</span> <span class="nv">tz</span> <span class="o">==</span> <span class="nv">TIME_ZONE</span> <span class="cp">%}</span> <span class="na">selected=</span><span class="s">"selected"</span><span class="cp">{%</span> <span class="k">endif</span> <span class="cp">%}</span><span class="nt">></span><span class="cp">{{</span> <span class="nv">tz</span> <span class="cp">}}</span><span class="nt"></option></span>
<span class="cp">{%</span> <span class="k">endfor</span> <span class="cp">%}</span>
<span class="nt"></select></span>
<span class="nt"><input</span> <span class="na">type=</span><span class="s">"submit"</span> <span class="na">value=</span><span class="s">"Set"</span> <span class="nt">/></span>
<span class="nt"></form></span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="s-time-zone-aware-input-in-forms">
<span id="s-time-zones-in-forms"></span><span id="time-zone-aware-input-in-forms"></span><span id="time-zones-in-forms"></span><h2>Time zone aware input in forms<a class="headerlink" href="#time-zone-aware-input-in-forms" title="Permalink to this headline">¶</a></h2>
<p>When you enable time zone support, Django interprets datetimes entered in
forms in the <a class="reference internal" href="#default-current-time-zone"><em>current time zone</em></a> and returns
aware datetime objects in <tt class="docutils literal"><span class="pre">cleaned_data</span></tt>.</p>
<p>If the current time zone raises an exception for datetimes that don’t exist or
are ambiguous because they fall in a DST transition (the timezones provided by
<a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> do this), such datetimes will be reported as invalid values.</p>
</div>
<div class="section" id="s-time-zone-aware-output-in-templates">
<span id="s-time-zones-in-templates"></span><span id="time-zone-aware-output-in-templates"></span><span id="time-zones-in-templates"></span><h2>Time zone aware output in templates<a class="headerlink" href="#time-zone-aware-output-in-templates" title="Permalink to this headline">¶</a></h2>
<p>When you enable time zone support, Django converts aware datetime objects to
the <a class="reference internal" href="#default-current-time-zone"><em>current time zone</em></a> when they’re rendered
in templates. This behaves very much like <a class="reference internal" href="formatting.html"><em>format localization</em></a>.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Django doesn’t convert naive datetime objects, because they could be
ambiguous, and because your code should never produce naive datetimes when
time zone support is enabled. However, you can force conversion with the
template filters described below.</p>
</div>
<p>Conversion to local time isn’t always appropriate – you may be generating
output for computers rather than for humans. The following filters and tags,
provided by the <tt class="docutils literal"><span class="pre">tz</span></tt> template tag library, allow you to control the time zone
conversions.</p>
<div class="section" id="s-template-tags">
<span id="template-tags"></span><h3>Template tags<a class="headerlink" href="#template-tags" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-localtime">
<span id="s-std:templatetag-localtime"></span><span id="localtime"></span><span id="std:templatetag-localtime"></span><h4>localtime<a class="headerlink" href="#localtime" title="Permalink to this headline">¶</a></h4>
<p>Enables or disables conversion of aware datetime objects to the current time
zone in the contained block.</p>
<p>This tag has exactly the same effects as the <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a> setting as far
as the template engine is concerned. It allows a more fine grained control of
conversion.</p>
<p>To activate or deactivate conversion for a template block, use:</p>
<div class="highlight-python"><pre>{% load tz %}
{% localtime on %}
{{ value }}
{% endlocaltime %}
{% localtime off %}
{{ value }}
{% endlocaltime %}</pre>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The value of <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a> isn’t respected inside of a
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">localtime</span> <span class="pre">%}</span></tt> block.</p>
</div>
</div>
<div class="section" id="s-timezone">
<span id="s-std:templatetag-timezone"></span><span id="timezone"></span><span id="std:templatetag-timezone"></span><h4>timezone<a class="headerlink" href="#timezone" title="Permalink to this headline">¶</a></h4>
<p>Sets or unsets the current time zone in the contained block. When the current
time zone is unset, the default time zone applies.</p>
<div class="highlight-python"><pre>{% load tz %}
{% timezone "Europe/Paris" %}
Paris time: {{ value }}
{% endtimezone %}
{% timezone None %}
Server time: {{ value }}
{% endtimezone %}</pre>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In the second block, <tt class="docutils literal"><span class="pre">None</span></tt> resolves to the Python object <tt class="docutils literal"><span class="pre">None</span></tt>
because it isn’t defined in the template context, not because it’s the
string <tt class="docutils literal"><span class="pre">None</span></tt>.</p>
</div>
</div>
<div class="section" id="s-get-current-timezone">
<span id="s-std:templatetag-get_current_timezone"></span><span id="get-current-timezone"></span><span id="std:templatetag-get_current_timezone"></span><h4>get_current_timezone<a class="headerlink" href="#get-current-timezone" title="Permalink to this headline">¶</a></h4>
<p>When the <tt class="xref py py-func docutils literal"><span class="pre">django.core.context_processors.tz()</span></tt> context processor is
enabled – by default, it is – each <a class="reference internal" href="../../ref/templates/api.html#django.template.RequestContext" title="django.template.RequestContext"><tt class="xref py py-class docutils literal"><span class="pre">RequestContext</span></tt></a>
contains a <tt class="docutils literal"><span class="pre">TIME_ZONE</span></tt> variable that provides the name of the current time
zone.</p>
<p>If you don’t use a <a class="reference internal" href="../../ref/templates/api.html#django.template.RequestContext" title="django.template.RequestContext"><tt class="xref py py-class docutils literal"><span class="pre">RequestContext</span></tt></a>, you can obtain
this value with the <tt class="docutils literal"><span class="pre">get_current_timezone</span></tt> tag:</p>
<div class="highlight-python"><pre>{% get_current_timezone as TIME_ZONE %}</pre>
</div>
</div>
</div>
<div class="section" id="s-template-filters">
<span id="template-filters"></span><h3>Template filters<a class="headerlink" href="#template-filters" title="Permalink to this headline">¶</a></h3>
<p>These filters accept both aware and naive datetimes. For conversion purposes,
they assume that naive datetimes are in the default time zone. They always
return aware datetimes.</p>
<div class="section" id="s-std:templatefilter-localtime">
<span id="s-id2"></span><span id="std:templatefilter-localtime"></span><span id="id2"></span><h4>localtime<a class="headerlink" href="#std:templatefilter-localtime" title="Permalink to this headline">¶</a></h4>
<p>Forces conversion of a single value to the current time zone.</p>
<p>For example:</p>
<div class="highlight-python"><pre>{% load tz %}
{{ value|localtime }}</pre>
</div>
</div>
<div class="section" id="s-utc">
<span id="s-std:templatefilter-utc"></span><span id="utc"></span><span id="std:templatefilter-utc"></span><h4>utc<a class="headerlink" href="#utc" title="Permalink to this headline">¶</a></h4>
<p>Forces conversion of a single value to UTC.</p>
<p>For example:</p>
<div class="highlight-python"><pre>{% load tz %}
{{ value|utc }}</pre>
</div>
</div>
<div class="section" id="s-std:templatefilter-timezone">
<span id="s-id3"></span><span id="std:templatefilter-timezone"></span><span id="id3"></span><h4>timezone<a class="headerlink" href="#std:templatefilter-timezone" title="Permalink to this headline">¶</a></h4>
<p>Forces conversion of a single value to an arbitrary timezone.</p>
<p>The argument must be an instance of a <tt class="xref py py-class docutils literal"><span class="pre">tzinfo</span></tt> subclass or a
time zone name. If it is a time zone name, <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> is required.</p>
<p>For example:</p>
<div class="highlight-python"><pre>{% load tz %}
{{ value|timezone:"Europe/Paris" }}</pre>
</div>
</div>
</div>
</div>
<div class="section" id="s-migration-guide">
<span id="s-time-zones-migration-guide"></span><span id="migration-guide"></span><span id="time-zones-migration-guide"></span><h2>Migration guide<a class="headerlink" href="#migration-guide" title="Permalink to this headline">¶</a></h2>
<p>Here’s how to migrate a project that was started before Django supported time
zones.</p>
<div class="section" id="s-database">
<span id="database"></span><h3>Database<a class="headerlink" href="#database" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-postgresql">
<span id="postgresql"></span><h4>PostgreSQL<a class="headerlink" href="#postgresql" title="Permalink to this headline">¶</a></h4>
<p>The PostgreSQL backend stores datetimes as <tt class="docutils literal"><span class="pre">timestamp</span> <span class="pre">with</span> <span class="pre">time</span> <span class="pre">zone</span></tt>. In
practice, this means it converts datetimes from the connection’s time zone to
UTC on storage, and from UTC to the connection’s time zone on retrieval.</p>
<p>As a consequence, if you’re using PostgreSQL, you can switch between <tt class="docutils literal"><span class="pre">USE_TZ</span>
<span class="pre">=</span> <span class="pre">False</span></tt> and <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">True</span></tt> freely. The database connection’s time zone
will be set to <a class="reference internal" href="../../ref/settings.html#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a> or <tt class="docutils literal"><span class="pre">UTC</span></tt> respectively, so that Django
obtains correct datetimes in all cases. You don’t need to perform any data
conversions.</p>
</div>
<div class="section" id="s-other-databases">
<span id="other-databases"></span><h4>Other databases<a class="headerlink" href="#other-databases" title="Permalink to this headline">¶</a></h4>
<p>Other backends store datetimes without time zone information. If you switch
from <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">False</span></tt> to <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">True</span></tt>, you must convert your data from
local time to UTC – which isn’t deterministic if your local time has DST.</p>
</div>
</div>
<div class="section" id="s-code">
<span id="code"></span><h3>Code<a class="headerlink" href="#code" title="Permalink to this headline">¶</a></h3>
<p>The first step is to add <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">True</span></tt></a> to your settings
file and install <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> (if possible). At this point, things should mostly
work. If you create naive datetime objects in your code, Django makes them
aware when necessary.</p>
<p>However, these conversions may fail around DST transitions, which means you
aren’t getting the full benefits of time zone support yet. Also, you’re likely
to run into a few problems because it’s impossible to compare a naive datetime
with an aware datetime. Since Django now gives you aware datetimes, you’ll get
exceptions wherever you compare a datetime that comes from a model or a form
with a naive datetime that you’ve created in your code.</p>
<p>So the second step is to refactor your code wherever you instantiate datetime
objects to make them aware. This can be done incrementally.
<a class="reference internal" href="../../ref/utils.html#module-django.utils.timezone" title="django.utils.timezone: Timezone support."><tt class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></tt></a> defines some handy helpers for compatibility
code: <a class="reference internal" href="../../ref/utils.html#django.utils.timezone.now" title="django.utils.timezone.now"><tt class="xref py py-func docutils literal"><span class="pre">now()</span></tt></a>,
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.is_aware" title="django.utils.timezone.is_aware"><tt class="xref py py-func docutils literal"><span class="pre">is_aware()</span></tt></a>,
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.is_naive" title="django.utils.timezone.is_naive"><tt class="xref py py-func docutils literal"><span class="pre">is_naive()</span></tt></a>,
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.make_aware" title="django.utils.timezone.make_aware"><tt class="xref py py-func docutils literal"><span class="pre">make_aware()</span></tt></a>, and
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.make_naive" title="django.utils.timezone.make_naive"><tt class="xref py py-func docutils literal"><span class="pre">make_naive()</span></tt></a>.</p>
<p>Finally, in order to help you locate code that needs upgrading, Django raises
a warning when you attempt to save a naive datetime to the database:</p>
<div class="highlight-python"><pre>RuntimeWarning: DateTimeField received a naive datetime (2012-01-01 00:00:00) while time zone support is active.</pre>
</div>
<p>During development, you can turn such warnings into exceptions and get a
traceback by adding the following to your settings file:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">warnings</span>
<span class="n">warnings</span><span class="o">.</span><span class="n">filterwarnings</span><span class="p">(</span>
<span class="s">'error'</span><span class="p">,</span> <span class="s">r"DateTimeField received a naive datetime"</span><span class="p">,</span>
<span class="ne">RuntimeWarning</span><span class="p">,</span> <span class="s">r'django\.db\.models\.fields'</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-fixtures">
<span id="fixtures"></span><h3>Fixtures<a class="headerlink" href="#fixtures" title="Permalink to this headline">¶</a></h3>
<p>When serializing an aware datetime, the UTC offset is included, like this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="s">"2011-09-01T13:20:30+03:00"</span>
</pre></div>
</div>
<p>For a naive datetime, it obviously isn’t:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="s">"2011-09-01T13:20:30"</span>
</pre></div>
</div>
<p>For models with <a class="reference internal" href="../../ref/models/fields.html#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><tt class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></tt></a>s, this difference
makes it impossible to write a fixture that works both with and without time
zone support.</p>
<p>Fixtures generated with <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">False</span></tt>, or before Django 1.4, use the
“naive” format. If your project contains such fixtures, after you enable time
zone support, you’ll see <tt class="xref py py-exc docutils literal"><span class="pre">RuntimeWarning</span></tt>s when you load them. To get
rid of the warnings, you must convert your fixtures to the “aware” format.</p>
<p>You can regenerate fixtures with <a class="reference internal" href="../../ref/django-admin.html#django-admin-loaddata"><tt class="xref std std-djadmin docutils literal"><span class="pre">loaddata</span></tt></a> then <a class="reference internal" href="../../ref/django-admin.html#django-admin-dumpdata"><tt class="xref std std-djadmin docutils literal"><span class="pre">dumpdata</span></tt></a>.
Or, if they’re small enough, you can simply edit them to add the UTC offset
that matches your <a class="reference internal" href="../../ref/settings.html#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a> to each serialized datetime.</p>
</div>
</div>
<div class="section" id="s-faq">
<span id="s-time-zones-faq"></span><span id="faq"></span><span id="time-zones-faq"></span><h2>FAQ<a class="headerlink" href="#faq" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-setup">
<span id="setup"></span><h3>Setup<a class="headerlink" href="#setup" title="Permalink to this headline">¶</a></h3>
<ol class="arabic">
<li><p class="first"><strong>I don’t need multiple time zones. Should I enable time zone support?</strong></p>
<p>Yes. When time zone support is enabled, Django uses a more accurate model
of local time. This shields you from subtle and unreproducible bugs around
Daylight Saving Time (DST) transitions.</p>
<p>In this regard, time zones are comparable to <tt class="docutils literal"><span class="pre">unicode</span></tt> in Python. At first
it’s hard. You get encoding and decoding errors. Then you learn the rules.
And some problems disappear – you never get mangled output again when your
application receives non-ASCII input.</p>
<p>When you enable time zone support, you’ll encounter some errors because
you’re using naive datetimes where Django expects aware datetimes. Such
errors show up when running tests and they’re easy to fix. You’ll quickly
learn how to avoid invalid operations.</p>
<p>On the other hand, bugs caused by the lack of time zone support are much
harder to prevent, diagnose and fix. Anything that involves scheduled tasks
or datetime arithmetic is a candidate for subtle bugs that will bite you
only once or twice a year.</p>
<p>For these reasons, time zone support is enabled by default in new projects,
and you should keep it unless you have a very good reason not to.</p>
</li>
<li><p class="first"><strong>I’ve enabled time zone support. Am I safe?</strong></p>
<p>Maybe. You’re better protected from DST-related bugs, but you can still
shoot yourself in the foot by carelessly turning naive datetimes into aware
datetimes, and vice-versa.</p>
<p>If your application connects to other systems – for instance, if it queries
a Web service – make sure datetimes are properly specified. To transmit
datetimes safely, their representation should include the UTC offset, or
their values should be in UTC (or both!).</p>
<p>Finally, our calendar system contains interesting traps for computers:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">datetime</span>
<span class="gp">>>> </span><span class="k">def</span> <span class="nf">substract_one_year</span><span class="p">(</span><span class="n">value</span><span class="p">):</span> <span class="c"># DON'T DO THAT!</span>
<span class="gp">... </span> <span class="k">return</span> <span class="n">value</span><span class="o">.</span><span class="n">replace</span><span class="p">(</span><span class="n">year</span><span class="o">=</span><span class="n">value</span><span class="o">.</span><span class="n">year</span> <span class="o">-</span> <span class="mi">1</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">one_year_before</span><span class="p">(</span><span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="p">(</span><span class="mi">2012</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">10</span><span class="p">,</span> <span class="mi">0</span><span class="p">))</span>
<span class="go">datetime.datetime(2011, 3, 1, 10, 0)</span>
<span class="gp">>>> </span><span class="n">one_year_before</span><span class="p">(</span><span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="p">(</span><span class="mi">2012</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">29</span><span class="p">,</span> <span class="mi">10</span><span class="p">,</span> <span class="mi">0</span><span class="p">))</span>
<span class="gt">Traceback (most recent call last):</span>
<span class="c">...</span>
<span class="gr">ValueError</span>: <span class="n">day is out of range for month</span>
</pre></div>
</div>
<p>(To implement this function, you must decide whether 2012-02-29 minus
one year is 2011-02-28 or 2011-03-01, which depends on your business
requirements.)</p>
</li>
<li><p class="first"><strong>Should I install pytz?</strong></p>
<p>Yes. Django has a policy of not requiring external dependencies, and for
this reason <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> is optional. However, it’s much safer to install it.</p>
<p>As soon as you activate time zone support, Django needs a definition of the
default time zone. When pytz is available, Django loads this definition
from the <a class="reference external" href="http://en.wikipedia.org/wiki/Tz_database">tz database</a>. This is the most accurate solution. Otherwise, it
relies on the difference between local time and UTC, as reported by the
operating system, to compute conversions. This is less reliable, especially
around DST transitions.</p>
<p>Furthermore, if you want to support users in more than one time zone, pytz
is the reference for time zone definitions.</p>
</li>
</ol>
</div>
<div class="section" id="s-troubleshooting">
<span id="troubleshooting"></span><h3>Troubleshooting<a class="headerlink" href="#troubleshooting" title="Permalink to this headline">¶</a></h3>
<ol class="arabic">
<li><p class="first"><strong>My application crashes with</strong> <tt class="docutils literal"><span class="pre">TypeError:</span> <span class="pre">can't</span> <span class="pre">compare</span> <span class="pre">offset-naive</span></tt>
<tt class="docutils literal"><span class="pre">and</span> <span class="pre">offset-aware</span> <span class="pre">datetimes</span></tt> <strong>– what’s wrong?</strong></p>
<p>Let’s reproduce this error by comparing a naive and an aware datetime:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">datetime</span>
<span class="gp">>>> </span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
<span class="gp">>>> </span><span class="n">naive</span> <span class="o">=</span> <span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="o">.</span><span class="n">utcnow</span><span class="p">()</span>
<span class="gp">>>> </span><span class="n">aware</span> <span class="o">=</span> <span class="n">naive</span><span class="o">.</span><span class="n">replace</span><span class="p">(</span><span class="n">tzinfo</span><span class="o">=</span><span class="n">timezone</span><span class="o">.</span><span class="n">utc</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">naive</span> <span class="o">==</span> <span class="n">aware</span>
<span class="gt">Traceback (most recent call last):</span>
<span class="c">...</span>
<span class="gr">TypeError</span>: <span class="n">can't compare offset-naive and offset-aware datetimes</span>
</pre></div>
</div>
<p>If you encounter this error, most likely your code is comparing these two
things:</p>
<ul class="simple">
<li>a datetime provided by Django – for instance, a value read from a form or
a model field. Since you enabled time zone support, it’s aware.</li>
<li>a datetime generated by your code, which is naive (or you wouldn’t be
reading this).</li>
</ul>
<p>Generally, the correct solution is to change your code to use an aware
datetime instead.</p>
<p>If you’re writing a pluggable application that’s expected to work
independently of the value of <a class="reference internal" href="../../ref/settings.html#std:setting-USE_TZ"><tt class="xref std std-setting docutils literal"><span class="pre">USE_TZ</span></tt></a>, you may find
<a class="reference internal" href="../../ref/utils.html#django.utils.timezone.now" title="django.utils.timezone.now"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.timezone.now()</span></tt></a> useful. This function returns the current
date and time as a naive datetime when <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">False</span></tt> and as an aware
datetime when <tt class="docutils literal"><span class="pre">USE_TZ</span> <span class="pre">=</span> <span class="pre">True</span></tt>. You can add or subtract
<tt class="xref py py-class docutils literal"><span class="pre">datetime.timedelta</span></tt> as needed.</p>
</li>
<li><p class="first"><strong>I see lots of</strong> <tt class="docutils literal"><span class="pre">RuntimeWarning:</span> <span class="pre">DateTimeField</span> <span class="pre">received</span> <span class="pre">a</span> <span class="pre">naive</span>
<span class="pre">datetime</span></tt> <tt class="docutils literal"><span class="pre">(YYYY-MM-DD</span> <span class="pre">HH:MM:SS)</span></tt> <tt class="docutils literal"><span class="pre">while</span> <span class="pre">time</span> <span class="pre">zone</span> <span class="pre">support</span> <span class="pre">is</span> <span class="pre">active</span></tt>
<strong>– is that bad?</strong></p>
<p>When time zone support is enabled, the database layer expects to receive
only aware datetimes from your code. This warning occurs when it receives a
naive datetime. This indicates that you haven’t finished porting your code
for time zone support. Please refer to the <a class="reference internal" href="#time-zones-migration-guide"><em>migration guide</em></a> for tips on this process.</p>
<p>In the meantime, for backwards compatibility, the datetime is considered to
be in the default time zone, which is generally what you expect.</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">now.date()</span></tt> <strong>is yesterday! (or tomorrow)</strong></p>
<p>If you’ve always used naive datetimes, you probably believe that you can
convert a datetime to a date by calling its <tt class="xref py py-meth docutils literal"><span class="pre">date()</span></tt>
method. You also consider that a <tt class="xref py py-class docutils literal"><span class="pre">date</span></tt> is a lot like a
<tt class="xref py py-class docutils literal"><span class="pre">datetime</span></tt>, except that it’s less accurate.</p>
<p>None of this is true in a time zone aware environment:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">datetime</span>
<span class="gp">>>> </span><span class="kn">import</span> <span class="nn">pytz</span>
<span class="gp">>>> </span><span class="n">paris_tz</span> <span class="o">=</span> <span class="n">pytz</span><span class="o">.</span><span class="n">timezone</span><span class="p">(</span><span class="s">"Europe/Paris"</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">new_york_tz</span> <span class="o">=</span> <span class="n">pytz</span><span class="o">.</span><span class="n">timezone</span><span class="p">(</span><span class="s">"America/New_York"</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">paris</span> <span class="o">=</span> <span class="n">paris_tz</span><span class="o">.</span><span class="n">localize</span><span class="p">(</span><span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="p">(</span><span class="mi">2012</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">30</span><span class="p">))</span>
<span class="go"># This is the correct way to convert between time zones with pytz.</span>
<span class="gp">>>> </span><span class="n">new_york</span> <span class="o">=</span> <span class="n">new_york_tz</span><span class="o">.</span><span class="n">normalize</span><span class="p">(</span><span class="n">paris</span><span class="o">.</span><span class="n">astimezone</span><span class="p">(</span><span class="n">new_york_tz</span><span class="p">))</span>
<span class="gp">>>> </span><span class="n">paris</span> <span class="o">==</span> <span class="n">new_york</span><span class="p">,</span> <span class="n">paris</span><span class="o">.</span><span class="n">date</span><span class="p">()</span> <span class="o">==</span> <span class="n">new_york</span><span class="o">.</span><span class="n">date</span><span class="p">()</span>
<span class="go">(True, False)</span>
<span class="gp">>>> </span><span class="n">paris</span> <span class="o">-</span> <span class="n">new_york</span><span class="p">,</span> <span class="n">paris</span><span class="o">.</span><span class="n">date</span><span class="p">()</span> <span class="o">-</span> <span class="n">new_york</span><span class="o">.</span><span class="n">date</span><span class="p">()</span>
<span class="go">(datetime.timedelta(0), datetime.timedelta(1))</span>
<span class="gp">>>> </span><span class="n">paris</span>
<span class="go">datetime.datetime(2012, 3, 3, 1, 30, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)</span>
<span class="gp">>>> </span><span class="n">new_york</span>
<span class="go">datetime.datetime(2012, 3, 2, 19, 30, tzinfo=<DstTzInfo 'America/New_York' EST-1 day, 19:00:00 STD>)</span>
</pre></div>
</div>
<p>As this example shows, the same datetime has a different date, depending on
the time zone in which it is represented. But the real problem is more
fundamental.</p>
<p>A datetime represents a <strong>point in time</strong>. It’s absolute: it doesn’t depend
on anything. On the contrary, a date is a <strong>calendaring concept</strong>. It’s a
period of time whose bounds depend on the time zone in which the date is
considered. As you can see, these two concepts are fundamentally different,
and converting a datetime to a date isn’t a deterministic operation.</p>
<p>What does this mean in practice?</p>
<p>Generally, you should avoid converting a <tt class="xref py py-class docutils literal"><span class="pre">datetime</span></tt> to
<tt class="xref py py-class docutils literal"><span class="pre">date</span></tt>. For instance, you can use the <a class="reference internal" href="../../ref/templates/builtins.html#std:templatefilter-date"><tt class="xref std std-tfilter docutils literal"><span class="pre">date</span></tt></a>
template filter to only show the date part of a datetime. This filter will
convert the datetime into the current time zone before formatting it,
ensuring the results appear correctly.</p>
<p>If you really need to do the conversion yourself, you must ensure the
datetime is converted to the appropriate time zone first. Usually, this
will be the current timezone:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
<span class="gp">>>> </span><span class="n">timezone</span><span class="o">.</span><span class="n">activate</span><span class="p">(</span><span class="n">pytz</span><span class="o">.</span><span class="n">timezone</span><span class="p">(</span><span class="s">"Asia/Singapore"</span><span class="p">))</span>
<span class="go"># For this example, we just set the time zone to Singapore, but here's how</span>
<span class="go"># you would obtain the current time zone in the general case.</span>
<span class="gp">>>> </span><span class="n">current_tz</span> <span class="o">=</span> <span class="n">timezone</span><span class="o">.</span><span class="n">get_current_timezone</span><span class="p">()</span>
<span class="go"># Again, this is the correct way to convert between time zones with pytz.</span>
<span class="gp">>>> </span><span class="n">local</span> <span class="o">=</span> <span class="n">current_tz</span><span class="o">.</span><span class="n">normalize</span><span class="p">(</span><span class="n">paris</span><span class="o">.</span><span class="n">astimezone</span><span class="p">(</span><span class="n">current_tz</span><span class="p">))</span>
<span class="gp">>>> </span><span class="n">local</span>
<span class="go">datetime.datetime(2012, 3, 3, 8, 30, tzinfo=<DstTzInfo 'Asia/Singapore' SGT+8:00:00 STD>)</span>
<span class="gp">>>> </span><span class="n">local</span><span class="o">.</span><span class="n">date</span><span class="p">()</span>
<span class="go">datetime.date(2012, 3, 3)</span>
</pre></div>
</div>
</li>
</ol>
</div>
<div class="section" id="s-usage">
<span id="usage"></span><h3>Usage<a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h3>
<ol class="arabic">
<li><p class="first"><strong>I have a string</strong> <tt class="docutils literal"><span class="pre">"2012-02-21</span> <span class="pre">10:28:45"</span></tt> <strong>and I know it’s in the</strong>
<tt class="docutils literal"><span class="pre">"Europe/Helsinki"</span></tt> <strong>time zone. How do I turn that into an aware
datetime?</strong></p>
<p>This is exactly what <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> is for.</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">from</span> <span class="nn">django.utils.dateparse</span> <span class="kn">import</span> <span class="n">parse_datetime</span>
<span class="gp">>>> </span><span class="n">naive</span> <span class="o">=</span> <span class="n">parse_datetime</span><span class="p">(</span><span class="s">"2012-02-21 10:28:45"</span><span class="p">)</span>
<span class="gp">>>> </span><span class="kn">import</span> <span class="nn">pytz</span>
<span class="gp">>>> </span><span class="n">pytz</span><span class="o">.</span><span class="n">timezone</span><span class="p">(</span><span class="s">"Europe/Helsinki"</span><span class="p">)</span><span class="o">.</span><span class="n">localize</span><span class="p">(</span><span class="n">naive</span><span class="p">)</span>
<span class="go">datetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=<DstTzInfo 'Europe/Helsinki' EET+2:00:00 STD>)</span>
</pre></div>
</div>
<p>Note that <tt class="docutils literal"><span class="pre">localize</span></tt> is a pytz extension to the <tt class="xref py py-class docutils literal"><span class="pre">tzinfo</span></tt>
API. Also, you may want to catch <tt class="xref py py-exc docutils literal"><span class="pre">InvalidTimeError</span></tt>. The
documentation of pytz contains <a class="reference external" href="http://pytz.sourceforge.net/#example-usage">more examples</a>. You should review it
before attempting to manipulate aware datetimes.</p>
</li>
<li><p class="first"><strong>How can I obtain the current time in the local time zone?</strong></p>
<p>Well, the first question is, do you really need to?</p>
<p>You should only use local time when you’re interacting with humans, and the
template layer provides <a class="reference internal" href="#time-zones-in-templates"><em>filters and tags</em></a>
to convert datetimes to the time zone of your choice.</p>
<p>Furthermore, Python knows how to compare aware datetimes, taking into
account UTC offsets when necessary. It’s much easier (and possibly faster)
to write all your model and view code in UTC. So, in most circumstances,
the datetime in UTC returned by <a class="reference internal" href="../../ref/utils.html#django.utils.timezone.now" title="django.utils.timezone.now"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.timezone.now()</span></tt></a> will be
sufficient.</p>
<p>For the sake of completeness, though, if you really wanted the current time
in the local time zone, here’s how you would obtain it:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">datetime</span>
<span class="gp">>>> </span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
<span class="gp">>>> </span><span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="o">.</span><span class="n">now</span><span class="p">(</span><span class="n">tz</span><span class="o">=</span><span class="n">timezone</span><span class="o">.</span><span class="n">get_default_timezone</span><span class="p">())</span>
<span class="go">datetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)</span>
</pre></div>
</div>
<p>In this example, <a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> is installed and <a class="reference internal" href="../../ref/settings.html#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a> is
<tt class="docutils literal"><span class="pre">"Europe/Paris"</span></tt>.</p>
</li>
<li><p class="first"><strong>How can I see all available time zones?</strong></p>
<p><a class="reference external" href="http://pytz.sourceforge.net/">pytz</a> provides <a class="reference external" href="http://pytz.sourceforge.net/#helpers">helpers</a>, including a list of current time zones and a list
of all available time zones – some of which are only of historical
interest.</p>
</li>
</ol>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Time zones</a><ul>
<li><a class="reference internal" href="#overview">Overview</a></li>
<li><a class="reference internal" href="#concepts">Concepts</a><ul>
<li><a class="reference internal" href="#naive-and-aware-datetime-objects">Naive and aware datetime objects</a></li>
<li><a class="reference internal" href="#interpretation-of-naive-datetime-objects">Interpretation of naive datetime objects</a></li>
<li><a class="reference internal" href="#default-time-zone-and-current-time-zone">Default time zone and current time zone</a></li>
<li><a class="reference internal" href="#selecting-the-current-time-zone">Selecting the current time zone</a></li>
</ul>
</li>
<li><a class="reference internal" href="#time-zone-aware-input-in-forms">Time zone aware input in forms</a></li>
<li><a class="reference internal" href="#time-zone-aware-output-in-templates">Time zone aware output in templates</a><ul>
<li><a class="reference internal" href="#template-tags">Template tags</a><ul>
<li><a class="reference internal" href="#localtime">localtime</a></li>
<li><a class="reference internal" href="#timezone">timezone</a></li>
<li><a class="reference internal" href="#get-current-timezone">get_current_timezone</a></li>
</ul>
</li>
<li><a class="reference internal" href="#template-filters">Template filters</a><ul>
<li><a class="reference internal" href="#std:templatefilter-localtime">localtime</a></li>
<li><a class="reference internal" href="#utc">utc</a></li>
<li><a class="reference internal" href="#std:templatefilter-timezone">timezone</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#migration-guide">Migration guide</a><ul>
<li><a class="reference internal" href="#database">Database</a><ul>
<li><a class="reference internal" href="#postgresql">PostgreSQL</a></li>
<li><a class="reference internal" href="#other-databases">Other databases</a></li>
</ul>
</li>
<li><a class="reference internal" href="#code">Code</a></li>
<li><a class="reference internal" href="#fixtures">Fixtures</a></li>
</ul>
</li>
<li><a class="reference internal" href="#faq">FAQ</a><ul>
<li><a class="reference internal" href="#setup">Setup</a></li>
<li><a class="reference internal" href="#troubleshooting">Troubleshooting</a></li>
<li><a class="reference internal" href="#usage">Usage</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="formatting.html">Format localization</a></li>
<li>Next: <a href="../logging.html">Logging</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../../index.html">Django 1.4.5 documentation</a>
<ul><li><a href="../index.html">Using Django</a>
<ul><li><a href="index.html">Internationalization and localization</a>
<ul><li>Time zones</li></ul>
</li></ul></li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../../_sources/topics/i18n/timezones.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Feb 21, 2013</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="formatting.html" title="Format localization">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="../logging.html" title="Logging">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
