Opened 14 years ago

Closed 14 years ago

#12315 closed (invalid)

DateField incorrectly handled by administration site

Reported by: toplex Owned by: nobody
Component: contrib.admin Version: 1.1
Severity: Keywords: date DateField admin date_hierarchy
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I followed the Django guide in creating a Polls website, and I encountered a strange, but funny bug in the automatically created administration site.

The problematic model:

class Poll(models.Model):
	question = models.CharField(max_length=200)
	pub_date = models.DateTimeField('date published')
	def was_published_today(self):
		return self.pub_date.date() == datetime.date.today()
	was_published_today.short_description = "Published today?"
	def __unicode__(self):
		return self.question

The problematic admin object:

class PollAdmin(admin.ModelAdmin):
	fieldsets = [
		(None,					{'fields': ['question']}),
		('Date information',	{'fields': ['pub_date'], 'classes': ['collapse']})
	]
	inlines = [ChoiceInLine]
	list_display = ('question', 'pub_date', 'was_published_today')
	list_filter = ['pub_date']
	search_fields = ['question']
	date_hierarchy = 'pub_date'

I was going through the admin guide, and it was passed midnight (well, just like now). I played around with the admin site, as I noticed something strange - a poll I added with today's date (the new day), returned False in the was_published_today method.

I figured something funny is going on, so I played with the date hierarchy, and strangely (but expected), the hierarchy thing did not count this Poll object as today either - in fact, I had to go all the way back to This month filter to see it (I guessed the Today and Passed 7 days use a different checking method which involved a faulty subtracting, where as the This month and This year just compares).

I added useful screen shots - The date can be found at the top right of the screen, and the time (fuzzily) at the bottom (thank god for KDE's awesome plasmoids).

Attachments (4)

snapshot4.png (146.8 KB ) - added by toplex 14 years ago.
Screenshot showing the 'any date' filtering
snapshot5.png (144.1 KB ) - added by toplex 14 years ago.
Screenshot showing the 'today' filtering
snapshot6.png (143.0 KB ) - added by toplex 14 years ago.
Screenshot showing the 'Past 7 days filtering
snapshot7.png (146.7 KB ) - added by toplex 14 years ago.
Screenshot showing the 'This month' filtering

Download all attachments as: .zip

Change History (6)

by toplex, 14 years ago

Attachment: snapshot4.png added

Screenshot showing the 'any date' filtering

by toplex, 14 years ago

Attachment: snapshot5.png added

Screenshot showing the 'today' filtering

by toplex, 14 years ago

Attachment: snapshot6.png added

Screenshot showing the 'Past 7 days filtering

by toplex, 14 years ago

Attachment: snapshot7.png added

Screenshot showing the 'This month' filtering

comment:1 by toplex, 14 years ago

Component: Uncategorizeddjango.contrib.admin

Sorry, new to this, categorized as django.contrib.admin component.

comment:2 by Russell Keith-Magee, 14 years ago

Resolution: invalid
Status: newclosed

I strongly suspect that there is a timezone configuration issue here. The giveaway is that when you're on the 'today' filtering page, it's showing articles created on the 13th, even when the system clock says the 14th.

Django's default configuration file sets the timezone to America/Chicago, and this will affect the data stored in the database. If you're in a timezone ahead of Chicago (which is to say, most of them) your system clock will say it's the 14th, but Django and the database stack will say it's the 13th. If you're in a timezone behind Chicago, the opposite will happen.

If you set your settings.TIME_ZONE setting to your local timezone, the problem should go away.

Note: See TracTickets for help on using tickets.
Back to Top