[Django] #20546: New model – ApproximateDateField
Django
----------------------------------------------+--------------------
Reporter: vericule@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
Hi,
I would like to propose adding new model to handle approximate dates (by
approximate date I mean date without year, month and/or day specified). I
think working with these dates is quite common problem. I'm simply using
additional boolean fields to indicate which argument is missing, but I
don't consider it as an elegant solution. There is also custom model
available at https://github.com/dracos/django-date-extensions but I
haven't tested it and it hasn't seen any work in a while.
Please consider adding this feature. Thank you.
--
Ticket URL: <https://code.djangoproject.com/ticket/20546>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: vericule@… | Owner: nobody
Type: New feature | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aastrand):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Hello,
I have the same use case in my genealogy project. I have various
information for example for the birthday of my individuals like "Dec
1708", "Est.(imated to) 1706", "14 Jan 1708", "1702", etc. where I for
example want the persons properly ordered according to the birthday and
different kinds of filtering. I handle that in my views, and I would
assume there are quite few us that have a "not-so-elegant" and a "not-
very-efficient" model for handling similar use cases. I would prefer to
call it FlexibleDateField (in contrast to the python DateField that is in
Django), but I would also assume that the meaning of flexibility would
vary from user to user. Still, it is not possible to extend the present
DateField; one has to start from scratch so there should be some common
denominator.
--
Ticket URL: <https://code.djangoproject.com/ticket/20546#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by lukeplant):
There is no reason why this feature needs to live in Django core, and at
the moment I don't think there is a big demand for it.
If there is already a 3rd party solution, use that. If it is not
maintained, and there is only one, that is evidence there isn't a huge
amount of demand for this feature. Accepting this feature request will not
magically create some people willing to write and maintain this code, so
I'm going to have to WONTFIX, sorry.
Please bring this up on the DevelopersMailingList if you want to persuade
us that there is big demand for this feature and it needs to be in Django
itself.
--
Ticket URL: <https://code.djangoproject.com/ticket/20546#comment:2>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.5
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: new => closed
* resolution: => wontfix
Comment:
Indeed.
--
Ticket URL: <https://code.djangoproject.com/ticket/20546#comment:3>