Django Python: Today's date gives error "couldn't be interpreted in time zone America/Los_Angeles; it may be ambiguous or it may not exist."

Question

When I try to set my datetime field to today's date in two of my models via the admin I get the error "couldn't be interpreted in time zone America/Los_Angeles; it may be ambiguous or it may not exist". This only happens in these two models. If I try to set datetime to today's date in other models (most of which are not shown), there are no problems.

Here are the relevant models from model.py:

from django.db import models

# DateTimeField has no problem with today's date in this model
class Subject(models.Model):
    title = models.CharField(max_length=200, unique=True)
    date_created = models.DateTimeField('date created')
    times_viewed = models.IntegerField()

# Both DateTimeFields give an error in this model
class Discussion(models.Model):
    subject = models.ForeignKey(Subject)

    title = models.CharField(max_length=200)
    version = models.CharField(max_length=200)
    created = models.DateTimeField('date created')
    updated = models.DateTimeField('date updated')
    creator = models.CharField(max_length=200)

# DateTimeField gives an error in this model too
class DiscussionPost(models.Model):
    discussion = models.ForeignKey(Discussion)

    poster = models.CharField(max_length=200)
    text = models.TextField()
    posted = models.DateTimeField('date posted')

Here is the relevant part of admin.py:

from django.contrib import admin
from my_app.models import Subject, Discussion, DiscussionPost # and other irrelevant models

class DiscussionPostInline(admin.StackedInline):
    model = DiscussionPost
    extra = 1

class DiscussionAdmin(admin.ModelAdmin):
    fieldsets = [
        ('Title',        {'fields': ['title']}),
        ('Creator',      {'fields': ['creator']}),
        ('Date Created', {'fields': ['created']}),
        ('Date Updated', {'fields': ['updated']}),
    ]
    inlines = [DiscussionPostInline]
    list_display = ('title', 'creator', 'created', 'updated')

admin.site.register(Discussion, DiscussionAdmin)

DiscussionInline(admin.StackedInline):
    model = Discussion
    extra = 1

SubjectAdmin(admin.ModelAdmin):
    fieldsets = [
        (None,              {'fields': ['title']}),
        ('Times Viewed',    {'fields': ['times_viewed'], 'classes': ['collapse']}),
        ('Date Created',    {'fields': ['date_created'], 'classes': ['collapse']}),
    ]
    inlines = [DiscussionInline]
    list_display = ('title', 'times_viewed', 'date_created')
    list_filter = ['date_created']
    search_fields = ['title']
    date_hierarchy = 'date_created'

admin.site.register(Subject, SubjectAdmin)

If I manually change to a different day from the admin, I do not get the error. It is just when I use today's date (both manually and using now() ). Anybody know why this may be happening?

This admin structure is based on the second answer to this Django Admin nested inline.

UPDATE I changed the datetime within the admin and now it works. I didn't change anything in the models or admin so I am stumped as to why it wasn't working earlier this morning.

Answer 1

you've been mixing up naive datetime object while having USE_TZ = True. To create current time you need to use timezone.now() instead of datetime.now()

From pytz doc

The major problem we have to deal with is that certain datetimes may occur twice in a year. ... This means that if you try and create a time in the ‘US/Eastern’ timezone using the standard datetime syntax, there is no way to specify if you meant before of after the end-of-daylight-savings-time transition.

...

The best and simplest solution is to stick with using UTC. The pytz package encourages using UTC for internal timezone representation by including a special UTC implementation based on the standard Python reference implementation in the Python documentation.

...

If you pass None as the is_dst flag to localize(), pytz will refuse to guess and raise exceptions if you try to build ambiguous or non-existent times.

From django docs

Interpretation of naive datetime objects

When USE_TZ is True, Django still accepts naive datetime objects, in order to preserve backwards-compatibility. When the database layer receives one, it attempts to make it aware by interpreting it in the default time zone and raises a warning.

Unfortunately, during DST transitions, some datetimes don’t exist or are ambiguous. In such situations, pytz raises an exception. Other tzinfo implementations, such as the local time zone used as a fallback when pytz isn’t installed, may raise an exception or return inaccurate results. That’s why you should always create aware datetime objects when time zone support is enabled.

In practice, this is rarely an issue. Django gives you aware datetime objects in the models and forms, and most often, new datetime objects are created from existing ones through timedelta arithmetic. The only datetime that’s often created in application code is the current time, and timezone.now() automatically does the right thing.