Is it possible to support partial dates with the DateInput widget?

[SamuelJennings]

Hi, I do a lot of work in digitization and archiving of legacy data/datasets from various research institutions. One problem with such data is that dates are very often not recorded in full. This obviously presents a problem. On one hand, I'd prefer to use a proper date type at the database level to support date-based lookups/queries. On the other hand, I don't want to force users to enter data which is unknown/unclear to them.

At the model level, I solve this by using a PartialDateField from the django-partial-date package which handles conversion from an ISO format string to a proper date type. and back again. Unfortunately, I've never found a nice date widget to support entry of partial dates on the client side.

The DateInput for django-formset looks super and returns the correct format that I would require. I'm just curious if you think it's possible for date inputs in django-formset to optionally validate partial dates? E..g. "2025", "2025-10", "2025-10-22".

[jrief]

Well, internally I can store a date only as datatime.date object. Python doesn't allow me to create a date object where the day or month is missing or None.

>>> from datetime import date
>>> date(2025, 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function missing required argument 'day' (pos 3)
>>>

>>> date(2025, 10, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer
>>>

I therefore have no idea how to represent a partial date internally. Does Postgres or any other DB backend offer such a type? I have never heard of any. Is there any unofficial Python support for such a type? Having such a module would help me a lot. However, I don't want to be dependent on django-partial-date, that library doesn't seem to be maintained well.

[SamuelJennings]

However, I don't want to be dependent on django-partial-date, that library doesn't seem to be maintained well.

True. I thought the same but in the end I decided to close my eyes and jump. No major issues so far.

Django Partial Date (Basics)

At the python level, they just wrap datetime.date with a custom class that also keeps track of "precision".

class PartialDate:
    YEAR, MONTH, DAY = 0, 1, 2

    def __init__(self, date, precision=DAY):
        self.date = date
        self.precision = precision

    ...

date here is either a datetime.date object or an ISO string that gets parsed to a date object. It has it's limitations but it works fairly well.

At the DB level, they use a DateTimeField. Precision information is encoded in the seconds field of the datetime object.

At the model level, they simply convert between the datetime object returned by the DB and the PartialDate object described above. E.g.

class PartialDateField(models.Field):
    def from_db_value(self, value, expression, connection, context=None):
        if value is None:
            return value
        return PartialDate(value.date(), value.second)

    def to_python(self, value):
        if isinstance(value, PartialDate):
            return value

They also provide a form field for validating an ISO formatted string. However, it's just a regular text field which is not the most inspiring option for users.

Alternative

The only alternative I can see on the Django/DB side of things would be to use contribute_to_class to create both a date field AND a precision field. e.g.

class PartialDateField(fields.Field):

    def contribute_to_class(self, cls, name, private_only=False):
        super().contribute_to_class(cls, name, private_only)
        self.date_field = models.DateField(null=True, blank=True)
        self.precision_field = models.CharField(max_length=5, choices=[
            ('year', 'Year'),
            ('month', 'Month'),
            ('day', 'Day'),
        ], default='day')

        # dynamically add the two backing fields
        cls.add_to_class(f"{name}_date", self.date_field)
        cls.add_to_class(f"{name}_precision", self.precision_field)

IMO, this adds more complexity for no real gain. You would still be using a wrapper class around datetime.date for Python ops to maintain the precision information.