[Django] #26345: Unexpected DateRange behavior
Django
----------------------------------+-----------------
Reporter: dbinetti | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+-----------------
Asked on #django to no response, so filing here.
When saving a postgres DateRange object to a DateRangeField, the `bounds`
are always changed to the default, even if a different bounds is
requested. The date payload (upper or lower), is also changed according
to the new bounds. This may be as designed, but it unexpected from my
perspective.
For instance, my users may enter data in a form to express a two day event
as Jan 1 2016 - Jan 2 2106, '[]' (inclusive lower and inclusive upper.)
However, this is translated in the database as Jan 1 2016 - Jan 3 2016
'[)' (inclusive lower *exclusive* upper with changed date) so if I then
try to render the upper date directly, it will do so as Jan 3, confusing
the user (and the developer :-) !)
Yes, I could accommodate this with some display logic, but that strikes me
as the wrong approach. I've included a repo with a test demonstrating
what I was expecting to see.
https://github.com/dbinetti/djangodaterange
--
Ticket URL: <https://code.djangoproject.com/ticket/26345>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
----------------------------------+--------------------------------------
Reporter: dbinetti | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.9
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
Comment:
From [http://www.postgresql.org/docs/9.2/static/rangetypes.html the
PostgreSQL documentation]:
The built-in range types `int4range`, `int8range`, and `daterange` all
use a canonical form that includes the lower bound and excludes the upper
bound; that is, `[)`. User-defined range types can use other conventions,
however.
Do we need to duplicate this information in Django's docs? Actually
[https://docs.djangoproject.com/en/stable/ref/contrib/postgres/fields
/#range-fields they do say], "The default is lower bound included, upper
bound excluded." Maybe the implications of that statement are unclear?
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:1>
Django
----------------------------------+--------------------------------------
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.9
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by dbinetti):
Certainly was unclear from my perspective. The word "default" suggests an
initial position that is subject to further modification/override. Upon
reading the Postgres docs, I now see that it is a canonicalization that is
always returned, but even though I read that before I didn't fully
understand what was happening on the back-end. It was unclear to me that
the bounds is used to produce the canonicalization, but that the bounds
themselves were not persisted.
Make of that what you will.
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:2>
Django
--------------------------------------+------------------------------------
Reporter: dbinetti | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* owner: => nobody
* type: Bug => Cleanup/optimization
* component: contrib.postgres => Documentation
* stage: Unreviewed => Accepted
Comment:
Feel free to propose some clarifications.
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:3>
Django
--------------------------------------+------------------------------------
Reporter: dbinetti | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by dbinetti):
* Attachment "26345.patch" added.
Django
--------------------------------------+------------------------------------
Reporter: dbinetti | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* has_patch: 0 => 1
Comment:
Thanks for the draft, but this applies to `IntegerRangeField` and
`BigIntegerRangeField` as well. Here's an
[https://github.com/django/django/pull/6282 alternate proposal].
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:4>
Django
--------------------------------------+------------------------------------
Reporter: dbinetti | Owner: nobody
Component: Documentation | Version: 1.9
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"b3610f38facb33704c1fd77590c6a2fa07c40fa7" b3610f38]:
{{{
#!CommitTicketReference repository=""
revision="b3610f38facb33704c1fd77590c6a2fa07c40fa7"
Fixed #26345 -- Clarified which RangesFields always return a canonical
form.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:5>
Django
--------------------------------------+------------------------------------
Reporter: dbinetti | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.9
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"d3c2d82ddef4b2bcf9d3d0b1ac59d7d65f5a7406" d3c2d82d]:
{{{
#!CommitTicketReference repository=""
revision="d3c2d82ddef4b2bcf9d3d0b1ac59d7d65f5a7406"
[1.9.x] Fixed #26345 -- Clarified which RangesFields always return a
canonical form.
Backport of b3610f38facb33704c1fd77590c6a2fa07c40fa7 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26345#comment:6>