4

I'm running Django with Postgres.

  1. I want timezone-aware datetime objects returned from the database.
  2. I want all the datetimes in querysets to be set to the user's locale, not UTC.
  3. I can get timezone aware dates in querysets if I set USE_TZ=True in settings, but they are all in UTC.
  4. If USE_TZ=False and set TIME_ZONE='America/New_York', I can get my results back in the user's correct locale, but the dates are all naive.

How can I get timezone-aware datetimes in the user's locale returned in my querysets by default?

Looping through the results and setting them all manually is not an option. It's way too slow.

I'm not interested in Django's ability to convert the dates to the user's timezone at render time, i.e. in a template or serializer. I need the timezone shifted dates before the view for processing.

Note: I think I've read the entire Internet on this topic and found one SO post (Ouput timezone aware django datetime fields without filters) that comes close to the same problem I want to solve, but no solution was provided.

Community
  • 1
  • 1
rgilligan
  • 754
  • 5
  • 18
  • Why are you so convinced that you *need the timezone shifted dates before then for processing*? This is inconsistent with best practices. – Stephen Rauch Apr 07 '17 at 07:13
  • 1
    @StephenRauch Believe me, I'd love to keep the data in UTC if I could. I'm using pandas to do complex processing on millions of rows and, depending on what is asked, it might need to group results on day, month, or year. This grouping needs to occur on dates in the timezone of the user who requested it to be accurate in their report. Attempting to do this date shift in python grinds the system to a halt. – rgilligan Apr 07 '17 at 16:30
  • Have you considered adding another column that is just the user's date? IE. relative to users timezone. – Stephen Rauch Apr 07 '17 at 16:43
  • It still would not give me timezone-aware date objects from the database. Also, that would break two other best practices: storing dates in multiple time zones and duplicating information. – rgilligan Apr 12 '17 at 14:36
  • Calculated (Generated) columns in Databases are a common enough problem that many databases actually have SQL operations to generate them. There is nothing wrong with storing expensive to calculate, and often needed values in the database, even though its constituent parts come from the same database. – Stephen Rauch Apr 12 '17 at 15:04
  • I agree that calculated fields have their purpose, but you may be overlooking the crux of my issue. Postgres saves all dates as UTC in the db regardless of my data, and I have no issue with pulling dates out in a specific timezone quickly at the db level. The problem I'm having is, I believe, the limitations of the Django queryset and how it manages timezone information after the SQL query has been run and the queryset has been built. Short of patching Django itself, I haven't been able to find a way to have datetime(..., tzinfo=) date objects loaded into models. – rgilligan Apr 12 '17 at 15:59
  • 1
    Thanks for the discussion, btw. Currently, I'm getting by with naive date objects in the correct timezone needed. The issue with this is that I can't easily do any date math with dates in other timezones. – rgilligan Apr 12 '17 at 16:01

0 Answers0