Time Zone Problem when following on tutorial

144 views
Skip to first unread message

Jerry Wu

unread,
Jun 23, 2014, 6:34:03 PM6/23/14
to django...@googlegroups.com
Dear every one,

I am following the tutorial and meet with some problem with Time Zone part. Since I am in Shanghai, China (UTC+8) , I think it is necessary to reset the time part.

Below is what I tried but failed with valuerror incorrect timezone setting:

TIME_ZONE="UTC+8"
TIME_ZONE="UTC+8:00"

I have tried "Asia/Shanghai", it works, but I think it is kind of out-of-date style due to the description in the tutorial.

Could some one give me a hint?

Thans in advance.

Mike Dewhirst

unread,
Jun 23, 2014, 7:26:52 PM6/23/14
to django...@googlegroups.com
On 24/06/2014 8:34 AM, Jerry Wu wrote:
> Dear every one,
>
> I am following the tutorial
> <https://docs.djangoproject.com/en/1.6/intro/tutorial01/> and meet with
> some problem with Time Zone part. Since I am in Shanghai, China (UTC+8)
> , I think it is necessary to reset the time part.
>
> Below is what I tried but failed with valuerror incorrect timezone setting:
>
> TIME_ZONE="UTC+8"
> TIME_ZONE="UTC+8:00"
>
> I have tried "Asia/Shanghai", it works, but I think it is kind of
> out-of-date style due to the description
> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-TIME_ZONE>
> in the tutorial.

This a very good question. Especially considering the variability
between databases. At least I think so - I use Postgres and that seems
to store times in UTC. In my case it is accidentally just what I want so
I'm not changing anything.

But just in case, I use the following utility everywhere ...

import pytz
from datetime import datetime

def when():
return datetime.now(tz=pytz.utc)

I wish I understood (or had the time and brainspace to commit to memory)
exactly how it all works. I think the target audience for the
documentation is somewhat smarter than I.

Mike
>
> Could some one give me a hint?
>
> Thans in advance.
>
> --
> 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/fcda6aed-87ee-48f6-85d8-2b2906056b81%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/fcda6aed-87ee-48f6-85d8-2b2906056b81%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

Jerry Wu

unread,
Jun 24, 2014, 5:44:29 PM6/24/14
to django...@googlegroups.com
Thanks, Mike. 

I still have a question. In your code, which part should I change in order to set the time zone to Asia/Shanghai?

mi...@dewhirst.com.au

unread,
Jun 25, 2014, 2:43:04 AM6/25/14
to django...@googlegroups.com
On 25/06/2014 7:44 AM, Jerry Wu wrote:> Thanks, Mike.
>
> I still have a question. In your code, which part should I change in
> order to set the time zone to Asia/Shanghai?

My settings uses Australia/Melbourne and Postgres stores time correctly
as UTC+10 (or UTC+11 in daylight saving time).

But as it happens I'm in New Zealand for a couple of days. So I'll
change my laptop location to Wellington tonight and log in and create
some test entries and knowing when I do that I should be able to check
the results after switching the laptop back to Melbourne time.

Now I think of it I could pretend I'm in Shanghai :)

You can see from the above that I half-believe pytz uses the system
locale to figure out the UTC offset. But I suppose it might be TIME_ZONE
in settings.

Have to go out now. I'll report back later

Mike

mi...@dewhirst.com.au

unread,
Jun 25, 2014, 3:05:22 AM6/25/14
to django...@googlegroups.com
It respects the settings.py time zone not the system locale.

This means your question needs to be addressed by someone smarter than
me.

Sorry

Mike

Mike Dewhirst

unread,
Jun 25, 2014, 4:48:44 PM6/25/14
to django...@googlegroups.com
Jerry

I just figured it out and it is simple. Time is constant and all you need to do is decide how* you want to display it. The TIME_ZONE setting tells the server.

An event happens at the same time everywhere in the universe (there may be Einsteinian exceptions to this) and you can store that time in the database relative to UTC. If you choose Shanghai time in settings then all recorded times are stored/displayed as Shanghai time. That is totally fair. People elsewhere just need to know the system is runing on "Shanghai time"

I don't know why it was necessary to switch the Django default to UTC except that lots of people use and can think in UTC as well as local time. The entire aviation industry for example. There may be a tiny performance gain avoiding calculating a local time.

The backwards compatibility thing is vital because if you have history in your database you can't just switch the base from UTC+8 to UTC without making all the stored times invalid by 8 hours.

What do you think?

Mike

Jerry Wu

unread,
Jul 3, 2014, 9:57:23 AM7/3/14
to django...@googlegroups.com
Mike,

Sorry for the late reply.

Your explanation about "time is constant" makes sense to me. But I still didn't know what to do with time setting following the tutorial.

Anyway, I chose to use Asia/Shanghai instead of fashion code. 

So far so good.

Thank you very much.

Mike Dewhirst

unread,
Jul 3, 2014, 7:02:13 PM7/3/14
to django...@googlegroups.com
On 3/07/2014 11:57 PM, Jerry Wu wrote:
> Mike,
>
> Sorry for the late reply.
>
> Your explanation about "time is constant" makes sense to me. But I still
> didn't know what to do with time setting following the tutorial.

One day I'll do some experiments and *really* understand how it works.

My variables are:

TIME_ZONE = 'Australia/Melbourne'

- time stored in the database eg., "2014-06-30 22:46:29.037+10" which in
June is AEST - Australian Eastern Standard Time or in March "2014-03-05
13:48:15.164+11" is daylight saving time.

- USE_TZ = True

When I find the courage I will try setting TIME_ZONE = 'UTC' and see how
times are displayed. New ones and existing ones! Maybe I'll do it around
the next changeover to daylight saving in Melbourne.

Cheers

Mike
> <https://docs.djangoproject.com/en/1.6/intro/tutorial01/> and
> meet with some problem with Time Zone part. Since I am in
> Shanghai, China (UTC+8) , I think it is necessary to reset the
> time part.
>
> Below is what I tried but failed with valuerror incorrect
> timezone setting:
>
> TIME_ZONE="UTC+8"
> TIME_ZONE="UTC+8:00"
>
> I have tried "Asia/Shanghai", it works, but I think it is kind
> of out-of-date style due to the description
> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-TIME_ZONE>
> in the tutorial.
>
> Could some one give me a hint?
>
> Thans in advance.
>
> --
> 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/96dec3fb-1cb1-449b-99e1-8668c62105a4%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/96dec3fb-1cb1-449b-99e1-8668c62105a4%40googlegroups.com?utm_medium=email&utm_source=footer>.

Palmillo

unread,
Aug 20, 2015, 11:11:04 AM8/20/15
to Django users
Hi, sorry to bring this up again, but I am currently facing same issue here: following the tutorial (first time with both Django and Python).
I live in Buenos Aires, Argentina (UTC-3).  Therefore, I would like to set the time zone for this region.
I apologize, but although I serfed the web trying to find the answer, since I am not familiar with UTC codings, I still do not understand which code should I use at the TIME_ZONE parameter.
Can you please help me with it? Which of the following values should I use in the parameter?:
1) TIME_ZONE = 'UTC-3'
2) TIME_ZONE = 'UTC-03:00'
3) TIME_ZONE = 'America/Argentina'
4) TIME_ZONE = 'AR'

Many thanks in advance!!

Luis Zárate

unread,
Aug 20, 2015, 12:17:31 PM8/20/15
to django...@googlegroups.com
install pytz

$ pip install pytz

In settings USE_TZ = True

https://docs.djangoproject.com/en/1.8/topics/i18n/timezones/
And the time_zone is

TIME_ZONE = "America/Argentina/Buenos_Aires"

More details in
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones





--
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.

For more options, visit https://groups.google.com/d/optout.



--
"La utopía sirve para caminar" Fernando Birri


Tom Evans

unread,
Aug 20, 2015, 12:36:55 PM8/20/15
to django...@googlegroups.com
On Fri, Jul 4, 2014 at 12:01 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> On 3/07/2014 11:57 PM, Jerry Wu wrote:
>>
>> Mike,
>>
>> Sorry for the late reply.
>>
>> Your explanation about "time is constant" makes sense to me. But I still
>> didn't know what to do with time setting following the tutorial.
>
>
> One day I'll do some experiments and *really* understand how it works.
>
> My variables are:
>
> TIME_ZONE = 'Australia/Melbourne'
>
> - time stored in the database eg., "2014-06-30 22:46:29.037+10" which in
> June is AEST - Australian Eastern Standard Time or in March "2014-03-05
> 13:48:15.164+11" is daylight saving time.
>
> - USE_TZ = True

With USE_TZ=True, TIME_ZONE only controls the display of datetimes.
Django should be storing all the database values as UTC, and
converting them to TZ-aware when extracting from the database.

>
> When I find the courage I will try setting TIME_ZONE = 'UTC' and see how
> times are displayed. New ones and existing ones! Maybe I'll do it around the
> next changeover to daylight saving in Melbourne.
>

You probably don't want that, most users don't understand UTC. Always
store in UTC, but display in a human timezone.

Another thing you can do is to allow users to select their timezone
and persist it on their user/profile. You can then use a bit of
middleware to activate that timezone, or if not specified, revert back
to the one specified in settings. In code:

from django.utils import timezone
from django.conf import settings

class TimeZoneMiddleware(object):
"""
This middleware activates a user's timezone, so that all dates
we give them
are localised correctly.
"""
def process_request(self, request):
if request.user.is_authenticated():
if user.timezone:
try:
timezone.activate(profile.timezone)
return
except:
pass
timezone.activate(settings.TIME_ZONE)

Dates in the database would all be stored in UTC, and converted in to
whatever timezone the end user wishes to use.

Unfortunately, you can't easily determine timezone from HTTP headers,
but for bonus points, you can *request* it from the browser with
javascript and append that data to a form to allow you to provide a
"best guess".

I say "request", because you don't get back a useful timezone like
"Europe/Valencia", you will get "+0200", which is almost impossible to
map to a specific timezone. There are many timezones that have offset
"+0200" at certain points in the year...

Cheers

Tom

Palmillo

unread,
Aug 20, 2015, 4:52:58 PM8/20/15
to Django users
Many thanks too all!! You've been really helpful
Reply all
Reply to author
Forward
0 new messages