Having trouble understanding Timezone

[Ryan Causey]

Hello,

I'm new to Python and Django so please bear with me on this one.

I've been reading the Django docs, googling, and searching this mailing list on the proper configuration and usage of Django when USE_TZ = True. However, I'm still a bit fuzzy on things and would like clarification on the following:

1. The documentation says that when USE_TZ = True that "Django stores datetime 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." Does this mean that the TIME_ZONE setting in settings.py should be UTC? Or should it be the timezone in which the database server is located?
2. I am using a postgresql database, and the installation defaulted the database's timezone to my local one. In support of Django storing all datetime information in UTC in the database, does the database's timezone needs to be set to UTC? Or is it correct for the database's timezone to be the local one?
3. The documentation also says that one should use the UTC timezone in the code, and only convert to local time when dealing with end users. I take this to mean that in any code I write I should set tzinfo = UTC for all datetime objects I create programmatically and let Django translate them in forms and views to the end user's timezone automatically. Is this correct?

Thank you in advance for the help,

-Ryan Causey

[Avraham Serour]

1. you don't need to st the TIME_ZONE setting, leave at default

2. honestly I don't know how setting the timezone in postgres influences the data, but I believe it doesn't need to be in sync with django settings.

3. yes, this is a good recommendation

success

Avraham

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b37291e8-3d99-49a4-8e9a-13a6639ef29b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Dewhirst]

Ryan

I too went through USE_TZ and time zones etc but too long ago to
remember enough to answer your questions with any authority. However
this works for me ...

USE_TZ = True
TIME_ZONE = 'UTC'

At 18:23 (AESummertime) here in Melbourne Australia I just created a new
record in my Postgres 9.3 database. FWIW the Ubuntu 12.04 database
server runs on local time. I'm using a Windows 8.1 client and Django
1.8.8 dev server.

The model save() method fills in a datetime field if it is blank. It
uses my when() utility. See below.

Examining the new record in the database the date/time saved is ...

2016-01-07 18:23:53.710608+11

There is enough information there to represent a UTC time. Simply
subtract 11 hours. Then add whatever for another timezone. I don't know
if the Django framework does that automatically based on the client
system time but I'm not too concerned about that. I only care that we
are are not losing date/time data.

My when() utility was called by save() without argument. It goes like
this ...

def when(days=0):
"""Function to return a non-naive datetime."""
dday = datetime.now(tz=pytz.utc)
if days == 0:
return dday
ttime = datetime.time(dday)
return timezone.make_aware(datetime.combine(
datetime.fromordinal(dday.toordinal() + days), ttime), pytz.utc)

HTH

Mike

On 7/01/2016 2:36 PM, Ryan Causey wrote:
> Hello,
>
> I'm new to Python and Django so please bear with me on this one.
>
> I've been reading the Django docs, googling, and searching this mailing
> list on the proper configuration and usage of Django when USE_TZ = True.
> However, I'm still a bit fuzzy on things and would like clarification on
> the following:
>

> 1. The documentation says that when USE_TZ = True that "Django stores

> datetime 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." Does this mean that the TIME_ZONE
> setting in settings.py should be UTC? Or should it be the timezone
> in which the database server is located?

> 2. I am using a postgresql database, and the installation defaulted the

> database's timezone to my local one. In support of Django storing
> all datetime information in UTC in the database, does the database's
> timezone needs to be set to UTC? Or is it correct for the database's
> timezone to be the local one?

> 3. The documentation also says that one should use the UTC timezone in

> the code, and only convert to local time when dealing with end
> users. I take this to mean that in any code I write I should set
> tzinfo = UTC for all datetime objects I create programmatically and
> let Django translate them in forms and views to the end user's
> timezone automatically. Is this correct?
>
> Thank you in advance for the help,
>
> -Ryan Causey
>

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto:django...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b37291e8-3d99-49a4-8e9a-13a6639ef29b%40googlegroups.com

> <https://groups.google.com/d/msgid/django-users/b37291e8-3d99-49a4-8e9a-13a6639ef29b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Juan Miguel Paredes]

On Wed, Jan 6, 2016 at 11:06 PM, Ryan Causey <rcca...@gmail.com> wrote:

1. The documentation says that when USE_TZ = True that "Django stores datetime 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." Does this mean that the TIME_ZONE setting in settings.py should be UTC? Or should it be the timezone in which the database server is located?

The particular needs of your project should determine how to configure Django and your database server. Since you're asking here, let's assume you do want to support users on multiple timezones.  You *should* configure your database server's timezone to UTC in this case.  Now, for the Django settings, a common scenario is that you want to display datetime information to your users on *their* local timezone (which you can detect and/or give them an option to set or store in their profile). For this, one recommended approach is to store every datetime value in UTC, and only convert to a specific timezone for user-display purposes. That's exactly what USE_TZ = True is meant for.

From the 1.8 docs, regarding the TIME_ZONE parameter, it states: "When USE_TZ is True, this is the default time zone that Django will use to display datetimes in templates and to interpret datetimes entered in forms".  This means that, in the scenario described earlier, the value of TIME_ZONE specified in settings.py will act just as a default for the datetime conversion on user-display (templates, forms) and in form-processing (in order to convert a datetime value from the user's timezone to UTC).  You can customize the current timezone for the user's session. See more information in https://docs.djangoproject.com/en/1.8/topics/i18n/timezones/

2. I am using a postgresql database, and the installation defaulted the database's timezone to my local one. In support of Django storing all datetime information in UTC in the database, does the database's timezone needs to be set to UTC? Or is it correct for the database's timezone to be the local one?

As said before, it's recommended that, in order to support multiple timezone values in your database, you set the database server's timezone to UTC. A local timezone on the server could get you into some trouble, particularly if you are in a timezone with DST, and want to perform datetime-related calculations later.

 

3. The documentation also says that one should use the UTC timezone in the code, and only convert to local time when dealing with end users. I take this to mean that in any code I write I should set tzinfo = UTC for all datetime objects I create programmatically and let Django translate them in forms and views to the end user's timezone automatically. Is this correct?

 

Read carefully the information on https://docs.djangoproject.com/en/1.8/topics/i18n/timezones/ (remember to check the documentation specific to your Django version), it should help.

[Carl Meyer]

Hi Ryan,

On 01/06/2016 08:36 PM, Ryan Causey wrote:
> I've been reading the Django docs, googling, and searching this mailing
> list on the proper configuration and usage of Django when USE_TZ = True.
> However, I'm still a bit fuzzy on things and would like clarification on
> the following:
>

> 1. The documentation says that when USE_TZ = True that "Django stores

> datetime 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." Does this mean that the TIME_ZONE
> setting in settings.py should be UTC? Or should it be the timezone
> in which the database server is located?

Django will use UTC internally (by which I mean, return UTC from the
database, and return UTC from `django.utils.timezone.now`) regardless of
the TIME_ZONE setting. You can think of the TIME_ZONE setting as the
default "end-user timezone" for your application; it doesn't affect
internal storage of datetimes.

If you have users in different timezones and you store each user's
timezone (e.g. in a profile model or custom user model), you can call
`django.utils.timezone.activate` (e.g. in a middleware's
`process_request` method) to activate the current user's timezone, which
will automatically cause templates and forms to display datetimes in
their timezone. If you never call `timezone.activate`, templates and
forms will display datetimes in the timezone defined by the TIME_ZONE
setting.

So basically there are two types of applications: those with per-user
timezones, and those that assume all users are in the same timezone.

For the former, you should be calling `timezone.activate` on every
request, and it doesn't really matter what you set TIME_ZONE to.

For the latter, you should set TIME_ZONE to the time zone that you
assume all your users live in, or at least that all your users will be
OK seeing their datetimes represented in.

> 2. I am using a postgresql database, and the installation defaulted the

> database's timezone to my local one. In support of Django storing
> all datetime information in UTC in the database, does the database's
> timezone needs to be set to UTC? Or is it correct for the database's
> timezone to be the local one?

Much like Django, Postgres _always_ stores in UTC internally (see the
docs); the server timezone setting only affects what timezone you see
your timestamps in if you query them at the Postgres shell. So much like
Django's TIME_ZONE setting, the Postgres server timezone is for user
representation only, it doesn't affect internal storage.

Django always overrides the default Postgres server timezone with a
per-connection timezone of UTC when it connects, so really the Postgres
server timezone setting is irrelevant to a Django application. It'll
only make a difference if or when you connect to Postgres outside of Django.

> 3. The documentation also says that one should use the UTC timezone in

> the code, and only convert to local time when dealing with end
> users. I take this to mean that in any code I write I should set
> tzinfo = UTC for all datetime objects I create programmatically and
> let Django translate them in forms and views to the end user's
> timezone automatically. Is this correct?

This approach isn't strictly required, but Django (and I) strongly
recommend it. Working exclusively with UTC internally makes datetime
arithmetic straightforward. If you do datetime arithmetic with non-UTC
datetimes, you have to handle ambiguous and nonexistent datetimes around
DST transitions, which is a real pain. So yes: use UTC internally, and
let Django convert for you at the user-display boundary.

Carl

[Simon Charette]

*shameless plug*

If you're building an application with per-user timezones I would suggest you
have a look at django-sundial[1] which provides a database field to store
timezones and the required request middleware to retrieve and activate a user
timezone stored in session.

[1] https://github.com/charettes/django-sundial

Simon

[Ryan Causey]

Thank you everyone for your responses. I believe I have a clear understanding of how it all interacts and what I need to do on my end.

-Ryan Causey