#32513: SQLite3 Backend Falsly claims SQLite does not support Timezone aware
DateTimes
-------------------------------------+-------------------------------------
Reporter: Arthur Moore | Owner: udaykiran
Type: Bug | Status: new
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: datetime, timezone | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Aymeric Augustin):
I'm afraid there are some misunderstandings in this ticket.
**Misunderstanding 1**
The initial report says:
> I expect to be able to store a timezone aware DateTime Field. The SQLite
​documentation indicates that this is actually valid.
It proceeds to the conclusion that Django should support that.
This reasoning relies on the implicit assumption that Django commits to
supporting all features of all databases. This assumption is incorrect.
Django doesn't make that promise. Rather, it's focusing on providing a
convenient Python API for the most common use cases and escape hatches for
the less common ones.
Django is able to serialize various types of objects, but not all of them.
For example, timezone-aware datetimes aren't supported when support for
timezone-aware datetimes is disabled (USE_TZ = False). I'm sorry for the
tautology, but I'm having a hard time making sense of your resistance to
USE_TZ = True.
(As you noticed, there are differences of behavior in the PostgreSQL
backend for legacy reasons -- it happened to have limited support for
timezone-aware datetimes before Django gained explicit support for
timezone-aware datetimes. That behavior was preserved for backwards-
compatibility reasons.)
If you'd like to store a timestamp with a particular timezone and later
retrieve the same timestamp and timezone, you have to use a custom field.
You can easily find third-party implementations of this functionality.
DateTimeField doesn't provide it; it doesn't remember the timezone. You
can store a timezone-aware datetime with any timezone attached, but when
you read it back, you always get a timezone-aware datetime in UTC
representing the same point in time. Then you can convert it back to any
timezone you like, and if you convert to the original timezone, of course
you get the original timestamp.
If you'd like to propose further changes in this area, #2626 and the
related thread on the django-developers mailing list would be good places
to start. After reviewing the design, you can make an argument about
improving some parts. There were a few features added since the original
proposal but the general principles still hold.
**Misunderstanding 2**
The lack of support in Django's SQLite database backend is plainly stated
in the message you're quoting: "SQLite backend does not support ..." I'm
not seeing how Django is lying there; to me it looks like your requirement
("it should say that at least") is met. Did you confuse "SQLite backend"
(the component of Django) with "SQLite database" (the database itself)?
--
Ticket URL: <https://code.djangoproject.com/ticket/32513#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.84e5ec57e81eeb76731e1aa51332e17e%40djangoproject.com.
