Opened 11 years ago
Closed 11 years ago
#20546 closed New feature (wontfix)
New model – ApproximateDateField
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 1.5 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
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.
Change History (3)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
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.
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.