{{{
class Telemetry(models.Model):
time_stamp = models.DateTimeField()
}}}
Whitin this class/model the time_stamp field is correctly treated as a
Python `datetime` object
Telemetry has a OnetoOne relationship with another model:
{{{
class ExtraTelemetry(models.Model):
telemetry = models.OneToOneField(Telemetry, on_delete=models.CASCADE,
primary_key=True)
}}}
in this related ExtraTelemetery object I am fetching the value of the
DateTimeField with:
`self.telemetry.time_stamp`
You'd expect this to be a Python `datetime` object too, but instead it
returns a `str` object (e.g. `"2020-04-15T17:03:05Z"`)
I am only able to use the field as datetime object by parsing it myself
with `dateutil.parser.parse(self.telemetry.time_stamp)`
I think this is a bug, because it should be a datetime object and not a
string, even when fetched through a relationship.
Django version is 3.0.5 with Python3.8.2 and SQLite
--
Ticket URL: <https://code.djangoproject.com/ticket/31471>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* owner: nobody => ovkulkarni
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:1>
* owner: ovkulkarni => (none)
* status: assigned => new
Comment:
I was unable to reproduce this bug using Django 3.0.5, Python 3.8.0, and a
SQLite database. My models and REPL output are shown below:
models.py
{{{
from django.db import models
class Test(models.Model):
time_stamp = models.DateTimeField(auto_now=True)
class RelationTest(models.Model):
test_field = models.OneToOneField(Test, on_delete=models.CASCADE,
primary_key=True)
}}}
REPL:
{{{
$ ./manage.py shell
Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from app.models import *
>>> r = RelationTest.objects.get(test_field=1)
>>> r.test_field.time_stamp
datetime.datetime(2020, 4, 16, 19, 48, 44, 277170, tzinfo=<UTC>)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:2>
* status: new => closed
* resolution: => worksforme
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:3>
Comment (by Fonville):
Thanks for testing in a simple test case, unfortunately I am still hitting
the bug in the context of the app I am writing.
It is triggered during the running of a post_save receiver. I will
investigate a bit more, what factor in the context is relevant and how to
reproduce it!
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:4>
Comment (by Fonville):
Ok, I found the culprit, I was entering the datetime as a str into the
model with the DateTimeField using a update_or_create() method as a kwarg.
Depending on whether the update_or_create had triggered a save (and thus
parsing) of the field, the field was either a string or a datetime.
I am not sure what your take is on things, but imho the nondeterministic
behaviour of update_or_create() is in my opinion not expected by a
developer.
I would expect even if the object is not updated in the database, the
field to still be parsed into a datetime in the object returned by the
update_or_create() method.
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:5>
* component: Uncategorized => Database layer (models, ORM)
Comment:
While I haven't investigated the details here, I'm inclined to say that
behavior probably won't change. See, for example, past tickets like
#12401.
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:6>
Comment (by Fonville):
Thanks for your explanation with the past ticket.
Maybe it is good to document somewhere these kind of gotchas that
(underwater) `.save()` can change the fieldtypes of the model object.
--
Ticket URL: <https://code.djangoproject.com/ticket/31471#comment:7>