I'm using Postgres
I have USE_TZ=True
I have TIME_ZONE='America/Los Angeles'
I am about to switch TIME_ZONE to UTC.
Will there be negative effects, gotchas, or anything I need to consider? Or will it just work since the date time is standardized? (I notice in my db rows that dates are stored with +08, which is indeed America/Los Angeles.)
The documentation mentions that if I use Postgres, I can swap USE_TZ freely, but doesn't mention changing TIME_ZONE.
Django always stores date time in UTC and now() always returns time in UTC or according to db.
so if you convert it using localtime() it will not affect how the value is stored.
The thing which matters is how it is presented to user.
I want to set Django timezone so that clock should remain consistent with local time in Florida, which is Eastern+Daylight Savings Time (DST). Please suggest the changes to the Django settings timezone such that it is consistent with this time zone; currently the django is set for EST (Eastern Standard Time) rather than EDT (Eastern Daylight Time). It should automatically change when we enter/leave DST.
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# If running in a Windows environment this must be set to the same as your
# system time zone.
TIME_ZONE = 'America/Chicago'
I am running my application in amazon ubuntu. What is the best time_zone to use for Florida local time. I am using Django 1.5.
Correct timezone name (from tz database) for Florida is "America/New_York", simply put that into your TIME_ZONE setting instead of "America/Chicago"
Here is a list of time zones along with their string values:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Setting it to America/New_York will cover most eastern states. Refer to the wikipedia for a list of all possible options.
I'm now going through the process of making a django application time zone aware. Initially, the TIME_ZONE setting was set to "America/Los_Angeles", but I've decided that it's probably more standard to make it "UTC".
I discovered some unintended behavior when I render a datetime to a web page in Javascript like so (start_date is a naive datetime that I define earlier in the view):
django view: cal_start_date = time.mktime(start_date.timetuple())
js: startDate = new Date(response.cal_start_date * 1000)
Depending on the TIME_ZONE I set in settings.py, I get a different timestamp for cal_start_date which is understandable: the time.mktime method returns a floating point number representing the number of seconds since the epoch (01/01/1970). However, the number of seconds since the epoch depends on the time zone we are referring to. I believe that time.mktime is automatically taking the TIME_ZONE setting as the one to use for this reference, right?
In general, is it bad practice to change the django TIME_ZONE setting?
Take a look this answer:
time.mktime() assumes that the passed tuple is in local time,
calendar.timegm() assumes it's in GMT/UTC. Depending on the
interpretation the tuple represents a different time, so the functions
return different values (seconds since the epoch are UTC based).
The difference between the values should be equal to the time zone
offset of your local time zone.
I also recomend you ensure that USE_TZ = True in your settings.py
I am developing a Django application that is based around event information. My client is sending all date/time information in UTC and making the conversion to local time. These are then sent to the server as a string. Furthermore, I'm using Postgres as the DB which also stores information in UTC.
Timezone support is active, but I am placing naive datetimes into Django and am receiving warnings. Do I even need time zone support for my application?
If so, how can I resolve the warnings?
USE_TZ = True # to activate time zone setting.
TIME_ZONE = 'America/Chicago' # set your timezone
When you activate time zone setting, DJango shows warning for each time you set Naive date time in your cod. Nothing to panic. You need to change your code to use Aware date time step by step.
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#concepts
from django.utils.timezone import utc, now
class SomeModel(Model):
schedule = django_models.DateTimeField(default=now)
I would highly encourage that you use pytz module. It makes working with timezones less painful.
How well does Django handle the case of different timezones for each user? Ideally I would like to run the server in the UTC timezone (eg, in settings.py set TIME_ZONE="UTC") so all datetimes were stored in the database as UTC. Stuff like this scares me which is why I prefer UTC everywhere.
But how hard will it be to store a timezone for each user and still use the standard django datetime formatting and modelform wrappers. Do I anticipate having to write date handling code everywhere to convert dates into the user's timezone and back to UTC again?
I am still going through the django tutorial but I know how much of a pain it can be to deal with user timezones in some other frameworks that assume system timezone everywhere so I thought I'd ask now.
My research at the moment consisted of searching the django documentation and only finding one reference to timezones.
Additional:
There are a few bugs submitted concerning Django and timezone handling.
Babel has some contrib code for django that seems to deal with timezone formatting in locales.
Update, January 2013: Django 1.4 now has time zone support!!
Old answer for historical reasons:
I'm going to be working on this problem myself for my application. My first approach to this problem would be to go with django core developer Malcom Tredinnick's advice in this django-user's post. You'll want to store the user's timezone setting in their user profile, probably.
I would also highly encourage you to look into the pytz module, which makes working with timezones less painful. For the front end, I created a "timezone picker" based on the common timezones in pytz. I have one select box for the area, and another for the location (e.g. US/Central is rendered with two select boxes). It makes picking timezones slightly more convenient than wading through a list of 400+ choices.
It's not that hard to write timezone aware code in django:
I've written simple django application which helps handle timezones issue in django projects: https://github.com/paluh/django-tz. It's based on Brosner (django-timezone) code but takes different approach to solve the problem - I think it implements something similar to yours and FernandoEscher propositions.
All datetime values are stored in data base in one timezone (according to TIME_ZONE setting) and conversion to appropriate value (i.e. user timezone) are done in templates and forms (there is form widget for datetimes fields which contains additional subwidget with timezone). Every datetime conversion is explicit - no magic.
Additionally there is per thread cache which allows you simplify these datatime conversions (implementation is based on django i18n translation machinery).
When you want to remember user timezone, you should add timezone field to profile model and write simple middleware (follow the example from doc).
Django doesn't handle it at all, largely because Python doesn't either. Python (Guido?) has so far decided not to support timezones since although a reality of the world are "more political than rational, and there is no standard suitable for every application."
The best solution for most is to not worry about it initially and rely on what Django provides by default in the settings.py file TIME_ZONE = 'America/Los_Angeles' to help later on.
Given your situation pytz is the way to go (it's already been mentioned). You can install it with easy_install. I recommend converting times on the server to UTC on the fly when they are asked for by the client, and then converting these UTC times to the user's local timezone on the client (via Javascript in the browser or via the OS with iOS/Android).
The server code to convert times stored in the database with the America/Los_Angeles timezone to UTC looks like this:
>>> # Get a datetime from the database somehow and store into "x"
>>> x = ...
>>>
>>> # Create an instance of the Los_Angeles timezone
>>> la_tz = pytz.timezone(settings.TIME_ZONE)
>>>
>>> # Attach timezone information to the datetime from the database
>>> x_localized = la_tz.localize(x)
>>>
>>> # Finally, convert the localized time to UTC
>>> x_utc = x_localized.astimezone(pytz.utc)
If you send x_utc down to a web page, Javascript can convert it to the user's operating system timezone. If you send x_utc down to an iPhone, iOS can do the same thing, etc. I hope that helps.
Not a Django expert here, but afaik Django has no magic, and I can't even imagine any such magic that would work.
For example: you don't always want to save times in UTC. In a calendar application, for example, you want to save the datetime in the local time that the calendar event happens. Which can be different both from the servers and the users time zone. So having code that automatically converts every selected datetime to the servers time zone would be a Very Bad Thing.
So yes, you will have to handle this yourself. I'd recommend to store the time zone for everything, and of course run the server in UTC, and let all the datetimes generated by the application use UTC, and then convert them to the users time zone when displaying. It's not difficult, just annoying to remember. when it comes to datetimes that are inputted by the user, it's dependant on the application if you should convert to UTC or not. I would as a general recommendation not convert to UTC but save in the users time zone, with the information of which time zone that is.
Yes, time zones is a big problem. I've written a couple of blog posts on the annoying issue, like here: http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/
In the end you will have to take care of time zone issues yourself, because there is no real correct answer to most of the issues.
You could start by taking a look at the django-timezones application. It makes available a number of timezone-based model fields (and their corresponding form fields, and some decorators), which you could use to at least store different timezone values per user (if nothing else).
Looking at the django-timezones application I found that it doesn't support MySQL DBMS, since MySQL doesn't store any timezone reference within datetimes.
Well, I think I manage to work around this by forking the Brosner library and modifying it to work transparently within your models.
There, I'm doing the same thing the django translation system do, so you can get user unique timezone conversion. There you should find a Field class and some datetime utils to always get datetimes converted to the user timezone. So everytime you make a request and do a query, everything will be timezoned.
Give it a try!