Django时区UTC

Question

I am currently working on Django project with a postgres DB. The data stored in db with time-stamp using Naive time (user's local time). However, in the setting.py, we have

USE_TZ = True

which means all the time-stamps retrieved by Django ORM are converted to UTC.

Generally, it is ok. However, for the function I am building right now does need the real time (uesr's local time). Certainly, I would fetch the data and convert the time to whatever time I want, with two problems: 1. I can convert time-stamps to EST or anything, but I still don't know the original time; 2. I want to do the converting during the ORM query rather than after, since it will be more efficient.

Does anyone have a clue about this? Thanks in advance!

Answer 1

1) If the original datetimes really are naive then I would assume they got stored as whatever timezone you have set in your TIME_ZONE setting (defaults to 'America/Chicago' but might be something else in your case). So converting back to that timezone will probably give you the original time. From the django docs:

"When USE_TZ is False, this is the time zone in which Django will store all datetimes. 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."

( https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-TIME_ZONE )

Normally the timezone information is actually set on the db connection ( https://docs.djangoproject.com/en/dev/ref/databases/#optimizing-postgresql-s-configuration ), so it's expected that you don't get your datetime in UTC when connecting to postgres through psql since the timezone used will default to your system's timezone, I'm not sure why this doesn't happen with raw queries in django though.

2) I can't say I've done many hours of research, however I believe that setting USE_TZ kind of dooms you to have to convert post-query. You can possibly override the connection timezone, but I don't know of an easy way to do this at runtime since it will default to UTC due to USE_TZ .

On previous projects I've worked on and ran into similar issues we have either passed the responsibility over to the front-end as someone suggested in your comments(frontend returns UTC datetimes and converts data back from UTC) or we also store the user timezone and do a post-query conversion. This didn't prove to be inefficient in our use case.