[Django] #23803: DateField returns datetime if SQLite field is created as TIMESTAMP

16 views
Skip to first unread message

Django

unread,
Nov 12, 2014, 6:53:41 AM11/12/14
to django-...@googlegroups.com
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
----------------------------------------------+--------------------
Reporter: me21 | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
I have SQLite database where certain column in table is created as
//TIMESTAMP//. The database is created not by Django, but by SymmetricDS,
a DB replication software. The database is replicated from Microsoft SQL
Server 2005, where it has //datetime// type.
In my Django application, the model has DateField for that column. The
returned value has //datetime// type, not //date//.

If I use the same model with Microsoft SQL Server 2005 (using django-
pyodbc-azure package), the returned value has //date// type, even though
the underlying column has //datetime// type.

I believe that DateField should return //date// always, regardless of DB
backend. Please consider altering the behaviour.

--
Ticket URL: <https://code.djangoproject.com/ticket/23803>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Nov 15, 2014, 8:26:26 AM11/15/14
to django-...@googlegroups.com
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
-------------------------------------+-------------------------------------

Reporter: me21 | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by mrbox):

* needs_better_patch: => 0
* version: 1.6 => master
* stage: Unreviewed => Accepted
* needs_tests: => 0
* needs_docs: => 0


Comment:

I agree that described behaviour exists. Steps to reproduce:

1. Create model like this:


{{{
class DateTimeModel(models.Model):
date_field = models.DateField()
}}}

2. makemigrations & migrate
3. Change manually type of date_field column to TIMESTAMP
4. Add an entry with TIMESTAMP for example `2010-08-28T13:40:02.200`
5. In django shell execute DateTimeModel.objects.first().date_field
6. Output is datetime.datetime(2010, 8, 28, 13, 40, 2, 200000,
tzinfo=<UTC>)

However I'm not sure what should be correct behaviour- should DateField
parse this as date or rather throw an exception?

--
Ticket URL: <https://code.djangoproject.com/ticket/23803#comment:1>

Django

unread,
Jan 20, 2015, 4:30:32 AM1/20/15
to django-...@googlegroups.com
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
-------------------------------------+-------------------------------------
Reporter: me21 | Owner: nobody
Type: Bug | Status: closed

Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by mjtamlyn):

* status: new => closed
* resolution: => wontfix


Comment:

Unfortunately, if django were to inspect every value of every field of
every model it loaded to ensure it is in the correct format there would be
a serious performance problem. Consequently care is taken to only apply
`db_converters` when they are necessary (we are still a little heavy
handed with them in some cases though).

If you wished to create a `DateField` subclass which would handle that,
you can use `from_db_value` in Django 1.8
(https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.Field.from_db_value)

--
Ticket URL: <https://code.djangoproject.com/ticket/23803#comment:2>

Django

unread,
Jan 20, 2015, 10:05:28 AM1/20/15
to django-...@googlegroups.com
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
-------------------------------------+-------------------------------------
Reporter: me21 | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by me21):

But it is somewhat counterintuitive. I didn't expect, for example, a
DateField which returns **datetime** objects. At least it should be
documented as known issue.
The reference on DateField says:
A date, represented in Python by a datetime.date instance.

On the other hand, when I use Microsoft SQL Server (with django-pyodbc-
azure and pyodbc), I get **date** from DateField, and **datetime** if I
change the model's field to DateTimeField. Why the same couldn't be done
for SQLite?

--
Ticket URL: <https://code.djangoproject.com/ticket/23803#comment:3>

Django

unread,
Jan 20, 2015, 10:20:25 AM1/20/15
to django-...@googlegroups.com
#23803: DateField returns datetime if SQLite field is created as TIMESTAMP
-------------------------------------+-------------------------------------
Reporter: me21 | Owner: nobody

Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by aaugustin):

You're merely seeing the consequences of SQLite's loose typing system. The
type of a value is only determined by inspecting the value.

You wouldn't notice it if the database was managed by Django because the
database would never contain values that don't cast to the correct type.

Perhaps django-pyodbc-azure performs a cast in that case, however, we
don't want to do that in Django because that's a performance critical code
path.

Interacting with external databases -- i.e. databases not created by
Django -- requires mapping columns according to their type. Here you have
a column containing datetimes. You must map it to a DateTimeField. That's
all.

You can't alter the type of a column, putting the database schema out of
sync with Django's model definition, and expect things to keep working.

--
Ticket URL: <https://code.djangoproject.com/ticket/23803#comment:4>

Reply all
Reply to author
Forward
0 new messages