Code

Opened 2 years ago

Closed 2 years ago

#17715 closed Cleanup/optimization (fixed)

Got a RuntimeWarning when following the tutorial

Reported by: claudep Owned by: aaugustin
Component: Documentation Version: 1.4-beta-1
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

With the new timezone support, creating a Poll object as described in part 1 of the tutorial gives a RuntimeWarning:

>>> from polls.models import Poll, Choice
>>> import datetime
>>> p = Poll(question="What's up?", pub_date=datetime.datetime.now())
>>> p.save()
/home/claude/.../django/db/models/fields/__init__.py:808: RuntimeWarning:
  DateTimeField received a naive datetime (2012-02-17 13:39:45.928590) while time zone support is active.
  RuntimeWarning)

That's not nice for beginners :-(

Attachments (1)

17715.diff (12.4 KB) - added by aaugustin 2 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 2 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to aaugustin
  • Patch needs improvement unset
  • Status changed from new to assigned

The tutorial should be changed to use timezone.now() instead, and include a not about this, with a link to the timezone docs.

comment:2 Changed 2 years ago by aaugustin

  • Severity changed from Normal to Release blocker
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 2 years ago by aaugustin

  • Has patch set

I've reviewed the tutorial, and adapted parts 1 and 2 for time zone support.

The patch includes a few other minor fixes.

Changed 2 years ago by aaugustin

comment:4 Changed 2 years ago by aaugustin

Unfortunately, I've changed slightly the example to dodge a datetime => date conversion, which isn't deterministic for aware datetimes.

As a consequence:

  • either we'll have to update again the screenshots that were just updated in r17543 -- sorry Claude :/
  • or I can change back the name and description of this function, but then its name won't reflect its behavier, which isn't nice.

I would really appreciate if someone reviewed the patch before I commit it.

comment:5 Changed 2 years ago by akaariai

I can read through it today. I have already read through it quickly, and I think avoiding the harder issues with timezone handling is a good choice. However, to me it seems that new users must read through the timezone documentation (or perhaps the upcoming FAQ) to understand the gotchas in this area. There aren't many, but they are things that will likely be encountered in new projects. So, adding some links in the part I of the tutorial seems necessary.

comment:6 Changed 2 years ago by claudep

+1 for adding a link to time zone docs. Apart from that, it looks fine. Don't worry about updating the screenshots, I'm only a robot :-)

comment:7 Changed 2 years ago by akaariai

The changes look good. I can't spot anything obviously broken. A new user going through the tutorial is the best review here.

Avoiding the hard timezone issues in the tutorial is a good choice. But as said before, links to documentation explaining these things is needed. In general there are surprisingly hard issues due to Python's implementation of datetimes, and the problems with different databases. In addition, many new users haven't given enough thought to these issues. For example "which day is it now" type issues will surprise users. So, giving users pointers on how to deal with timezone issues as early as possible is good in my opinion.

Reiterating my thoughts here, but it would be just wonderful if there was a django.utils.datetime module which would be fully timezone aware when using USE_TZ=True. The common single-timezone setup, where UTC times are used just to dodge issues with DST issues could be handled fully hidden from the user. Use from django.utils import datetime where you used import datetime before. No other changes to tutorial needed. However, this is of course impossible to do for Django 1.4, and might be too hard/laborious to implement ever.

Version 0, edited 2 years ago by akaariai (next)

comment:8 Changed 2 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from assigned to closed

In [17591]:

Fixed #17715 -- Updated the tutorial for time zone support, plus a few other improvements.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.