Enable timezone support and set timezone to UTC

[davidfischer]

The two primary changes here are:

• Change TIME_ZONE from America/Chicago to UTC.
• Set USE_TZ to True (the default is False).

These are the defaults for new projects in Django.

Links

• Django's timezone migration guide

Notes

Our production database is already timezone aware so I don't believe this will cause issues with the production database. Django's docs say as much but it's worth a second look.

docs=> SELECT last_login, date_joined FROM auth_user WHERE username='xxx';
          last_login           |      date_joined
-------------------------------+------------------------
 2018-08-18 22:01:47.979033+00 | 2011-12-22 06:02:28+00
(1 row)

[humitos]

All your changes look correct to me. Although, I'm not 100% sure how to test other things or where we could find issues by changing these settings.

Maybe it's a good moment to upgrade pytz to 2018.05 (currenty 2018.04) together with these changes.

[davidfischer]

Although, I'm not 100% sure how to test other things or where we could find issues by changing these settings.

That's what terrifies me as well.

[ericholscher]

Sounds like it should be raising warnings in the console if we have issues, and I don't see any warnings in our tests. I'm guessing the primary issue is that we might end up with some dates in the future when we do the switch or something like that.

[davidfischer]

All the warnings that came from executing the test suite were fixed as part of this PR. I just suspect there might be some not covered by our tests.

Dates in the database should be ok.

[ericholscher]

I'm tempted to try and merge this in. If the DB is correct, then I think we'll be alright. Thoughts?

[codecov]

Codecov Report

Merging #4545 into master will increase coverage by <.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #4545      +/-   ##
==========================================
+ Coverage   76.41%   76.42%   +<.01%     
==========================================
  Files         158      158              
  Lines        9988     9992       +4     
  Branches     1262     1262              
==========================================
+ Hits         7632     7636       +4     
  Misses       2016     2016              
  Partials      340      340

Impacted Files	Coverage Δ
readthedocs/search/indexes.py	77.04% <100%> (ø)	⬆️
readthedocs/projects/views/base.py	89.06% <100%> (+0.17%)	⬆️
readthedocs/oauth/services/base.py	46.15% <33.33%> (+0.59%)	⬆️
readthedocs/projects/tasks.py	69.37% <50%> (+0.06%)	⬆️
readthedocs/core/admin.py	72.72% <66.66%> (+0.5%)	⬆️
readthedocs/projects/constants.py	100% <0%> (ø)	⬆️
readthedocs/doc_builder/backends/sphinx.py	69.8% <0%> (ø)	⬆️

[davidfischer]

I'm tempted to try and merge this in. If the DB is correct, then I think we'll be alright. Thoughts?

Let's aim for next week. I'll get the coverage into shape and re-run the test suite with Django 1.11.

[davidfischer]

I'm somewhat confused by the coverage results.

• the patch increases the project overall coverage (I’m not sure how) but is rejected because the diff coverage is too low.
• some files I didn’t modify are shown in the coverage report
• I’m not really sure how to get the patch coverage up without writing tests that test other functionality

I think we are ok here.

[ericholscher]

🎉