Breaking change: DateTimeField validation parsing

[RignonNoel]

We upgraded a Django project to the new version of Django (4.2.5) and DRF (3.14.0) and some of ours unit test failed due to breaking changes on the DateTimeField() parsing validation.

Example of serializer:

class MySerializer(serializers.Serializer):
    start_time = serializers.DateTimeField()

Example of data we tested:

2021-03-13

Example of exception we expected before:

Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm[:ss[.uuuuuu]][+HH:MM|-HH:MM|Z].

Now, it seems that 2021-03-13 is valid... But it's not at all matching the format proposed in the default error message that DRF use: YYYY-MM-DDThh:mm[:ss[.uuuuuu]][+HH:MM|-HH:MM|Z].

---

Different option i think:

1. We adapt the default error message. But for me it's a breaking change since a lot of platform will have datetime with a default 00:00:00 time on datetime in place of the error message they got before
2. We include a date format validation inside DRF to match the format we had before
3. We cooperate with Django repo to adapt the change they made since this change could have a lot of other repercution on a lot of other platform (making the parse_datetime() more clearly defined to avoid futur problem)

---

Here are my research

django-rest-framework/rest_framework/settings.py

Line 107 in f56b85b

'DATETIME_INPUT_FORMATS': [ISO_8601],

django-rest-framework/rest_framework/fields.py

Lines 1177 to 1198 in f56b85b

	def to_internal_value(self, value):
	input_formats = getattr(self, 'input_formats', api_settings.DATETIME_INPUT_FORMATS)
	if isinstance(value, datetime.date) and not isinstance(value, datetime.datetime):
	self.fail('date')
	if isinstance(value, datetime.datetime):
	return self.enforce_timezone(value)
	for input_format in input_formats:
	with contextlib.suppress(ValueError, TypeError):
	if input_format.lower() == ISO_8601:
	parsed = parse_datetime(value)
	if parsed is not None:
	return self.enforce_timezone(parsed)
	parsed = self.datetime_parser(value, input_format)
	return self.enforce_timezone(parsed)
	humanized_format = humanize_datetime.datetime_formats(input_formats)
	self.fail('invalid', format=humanized_format)

We see here that DRF clearly use ISO_8601 in the default settings and use the django parse_datetime() function to make the logic attached

https://github.com/django/django/blame/656192c2c96bb955a399d92f381e38fe2254fe17/django/utils/dateparse.py#L104-L130

But we see here that Django try to use datetime.fromisoformat() first since this commit of @kezabelle and fromisoformat() allow a LOT MORE format than before as you can see on their documentation

https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat

[auvipy]

I am open to see a PR with a failing test case atleast

[RignonNoel]

@auvipy I don't have any open-source repository with this problem right now on hand, and I don't have the time to create a full new repo of proof just for that. But please feel free to let me know what would be the best way to give you a better test if it's too complex for you to test the default validator by yourself.

Basically if you create any serialiser as simple as this one:

class MySerializer(serializers.Serializer):
    start_time = serializers.DateTimeField()

And that you give the value 2021-03-13 in input for validation (ie: MySerializer(data).is_valid()), you will get the problem I explained.

[auvipy]

Thanks. It seems to be a Django compat issue and I will look into it much further

[DNiemeijer]

I am running into the exact same issue as described above during a Django upgrade. Do you have an indication on when we can expect an update on this? Thanks in advance :)

[RignonNoel]

@DNiemeijer An issue has been opened here if you want to follow it also: #9161

[auvipy]

I would be happy to see any fix with minimal test case