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.