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
Related
I'm looking for a way to save datetimes with a specific timezone other than the established timezone, however I have the following settings:
TIME_ZONE = "UTC"
USE_TZ = True
This is convenient, since for the most part I want dates to be saved in UTC, however sometimes I need to keep track of the local datetimes the user setup.
Anyone has any idea how to save a datetime without being converted to the default timezone (UTC)?
I am using PostgreSQL, so I don't know if this is possible...
Any tips are welcome.
Watch out from storing dates with their timezone in database systems, as there are way too many years of questionable implementations piled up everywhere, from the engines themselves, thought the clients, to the various third party libraries (including the Django ORM).
For example, from the Postgres documentation:
All timezone-aware dates and times are stored internally in UTC. They
are converted to local time in the zone specified by the TimeZone
configuration parameter before being displayed to the client.
This means that if you save a datetime localized on timezone "Europe/Rome" from Django, with a client setup to use timezone "America/New_York" and then you read it with a client configured with timezone "Europe/London" you will get the British time corresponding to the original datetime, no matter what.
The only reliable way that I found for dealing with time zones using database systems is to save the timezone separately. For example, in a "timezone" filed of the user profile, or using a combination of a "timestamp" + "timezone" fields if storing events which are somehow sensitive to the timezone (i.e. logins, sensor readings, etc.).
In this way you can store all timestamps in UTC (which is what Postgres will do in any case anyway), and then localize them in your application once they are out from the database, which is much clearer, robust, and database-system independent.
Note that if you want to filer your timestamps (i.e. from, to) you will need to perform the queries on UTC, and if you want use time math (i.e. all logins of user X on mondays on timezone "America/New_York") it is going to be a pain in any scenario (you can get a taste here: PostgreSQL date() with timezone).
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'm using Django and when I retrieve instance (with objects.all()) the models.DateTime are changing so that 7 hours are added.
I'm in the US Pacific time zone and I'm guessing that my DB is defined as UTC I'm using PostgreSQL and I can't figure out where is the setting for time zone.
One other thing I'm also getting this warning:
RuntimeWarning: DateTimeField received a naive datetime while time zone support is active.
Maybe the two are connected?
settings.py：
TIME_ZONE = 'America/Los_Angeles'
# database not use UTC
USE_TZ = False
see this
Running a Django web app and settings.py has the following:
TIME_ZONE = 'UTC'
A model's time field is set to datetime.datetime.utcnow().
When I look at the field in the admin screen, it is correct with the UTC timestamp at +8 hours from my local time.
Yet when I display the time on the client, the time is yet another +8 (for a total +16 hours) from my local time.
When I step through the code, there is no change to the date. When the timestamp is queried from the database, it is +8 offset from the actual UTC.
What am I doing wrong? We are running the development environment on Windows and there has been some warning about results being inaccurate. But I've also pushed this to our Linux box and the results are identical.
In settings.py, if
USE_TZ = True
...then results might not be as expected. I believe there is documentation and I simply missed it. When I removed the setting, the times were being reported as expected.
Provided by #Two-BitAlchemist:
Here is the relevant documentation. In particular, if you do not have USE_TZ=True, it assumes every date you use is in your local time and converts it to UTC
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.