Fixed #5363 -- HTML5 datetime-local valid format HTMLFormRenderer #9365

mgaligniana · 2024-04-04T19:28:52Z

Description

Hi!

This PR delete everything after the first 3 digits of the miliseconds part of a DateTimeField input at HTMLFormRenderer to avoid break in browsers:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local#try_it

Please execute ./runtests.py TestDateTimeFieldHTMLFormRender to run the new tests

Fix #5363

mgaligniana · 2024-05-27T15:47:19Z

Hi @auvipy! Following your comment on #5363 (comment) I ask if you could do the review! Thank you!

rest_framework/renderers.py

stale · 2025-04-27T18:31:20Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

auvipy

please address the review comment

mgaligniana · 2025-04-28T03:50:36Z

Thanks @auvipy! I'll do it!

mgaligniana · 2025-06-10T13:41:57Z

Just an update here. I'm still active! I'll do as soon as possible

tests/test_renderers.py

mgaligniana · 2025-07-26T13:21:17Z

I finally did it, sorry for the long delay!

Copilot

Pull Request Overview

This PR fixes HTML5 datetime-local input formatting by truncating milliseconds to 3 digits to ensure browser compatibility. The HTML5 datetime-local input type specification only supports up to 3 digits of milliseconds precision, but DRF was potentially outputting more digits which caused browser validation errors.

Modifies the datetime-local field value formatting in HTMLFormRenderer to limit milliseconds to 3 digits
Adds a test case to verify the correct datetime-local input formatting

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
rest_framework/renderers.py	Updates datetime-local field formatting to truncate milliseconds to 3 digits
tests/test_renderers.py	Adds test case to verify datetime-local input formatting with milliseconds

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

rest_framework/renderers.py

tests/test_renderers.py

peterthomassen

Thanks. I have two more remarks:

Timezones currently get dropped, but I assume that's fine because this is about datetime-local which "represent[s] a local date and time, with no time-zone offset information".
The transformation assumes that the string format is iso-8601. It doesn't work if I specify, for example, appointment = serializers.DateTimeField(format='%a %d %b %Y, %I:%M%p'). Shouldn't the internal value be used as an input?

mgaligniana · 2025-08-19T19:53:26Z

Thank you Peter!

Not sure if I'm following: do you mean use the datetime value instead of the input.value (string)?

So let me know if you want to fix this in this pull request

peterthomassen · 2025-08-19T20:04:17Z

do you mean use the datetime value instead of the input.value (string)?

Yes, that's what I meant. Sorry for being unclear!

browniebroke · 2025-08-20T12:00:33Z

I tried to use this branch on a Django project with TIME_ZONE="Europe/Paris" and I'm getting a similar error as the original report, bacause the timezone is not Z but +02:00 at the end. While it feels a bit out of scope of what this fix is trying to do, this last suggestion could address it as well?

mgaligniana · 2025-08-20T13:21:47Z

Correct! I'll go for that approach and add one more test for that case Bruno! Thanks!

stale

rest_framework/renderers.py

browniebroke · 2025-08-21T08:06:40Z

tests/test_renderers.py

        assert rendered == ''


+class TestDateTimeFieldHTMLFormRender(TestCase):


It would be nice to add a couple of test cases with some non-naive datetimes, with a timezone specified. Could try with UTC and another timezone where the offset is non-zero

Thank you!

So I've added a docstring to let know that config variables are set in

USE_TZ=True TIME_ZONE='America/Chicago'

And added a fourth test where @override_settings(TIME_ZONE='UTC', USE_TZ=True)

Is that correct?

I guess so. You can confirm by setting format=None and printing field.value.

Let's also add a test for a timezone with non-zero offset.

mgaligniana · 2025-08-21T13:43:32Z

@browniebroke and @peterthomassen thank you so much for your quick reviews and guidance! 🙏

It would be nice to add a couple of test cases with some non-naive datetimes, with a timezone specified. Could try with UTC and another timezone where the offset is non-zero

Sure, I'll add a new test with timezone!

I'm not sure. Is it guaranteed that there is always a parent?

Good question. I didn't fully understand what is parent so I'll read more code to be sure and add new cases if needed!

mgaligniana · 2025-09-18T12:18:25Z

~~Hi team! Just to remember that I've added a new test and a question about .parent. Thank you!~~

Copilot

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

rest_framework/renderers.py

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

rest_framework/renderers.py

mgaligniana · 2025-10-15T03:32:18Z

Hello team! I went for a new approach: get datetime string and transform to datetime object to better manipulation.

I've added 7 tests in total! I think I covered all possible cases!

peterthomassen

I like the new approach, but I don't understand the typing considerations. You probably have thought about that -- any insights on my comments?

Also, the tests have quite some code duplication (I'm not sure if that is a problem).

rest_framework/renderers.py

peterthomassen · 2025-10-15T10:06:15Z

rest_framework/renderers.py

+                    datetime_field_value = datetime.datetime.strptime(field.value, field._field.format)
+            else:
+                if api_settings.DATETIME_FORMAT == ISO_8601:
+                    datetime_field_value = datetime.datetime.fromisoformat(field.value.rstrip('Z'))
+                else:
+                    datetime_field_value = datetime.datetime.strptime(field.value, api_settings.DATETIME_FORMAT)


These assume that field.value is a string. Earlier, this was checked in line 345, but it no longer is. This is only safe if field.value always is a string if either the format argument is not set or is not None. Is that guaranteed? (How?)

I now understand that when format=None, then field.value is a datetime object. Is it guaranteed that otherwise it is a string?

The docs you linked in the other conversation say:

Setting to a format string indicates that to_representation return values should be coerced to string output.

... so maybe the coercion should happen first before calling rstrip or passing to strptime?

I think so!

Following https://github.com/encode/django-rest-framework/blob/main/rest_framework/fields.py#L1198

Mmm, unless ... DATETIME_FORMAT can't be None right? And if it can you should set a format

DATETIME_FORMAT can't be None right?

It can be. So, in the last branch when format is not set and DATETIME_FORMAT is not equal to ISO_8601, DATETIME_FORMAT may be None in which case field.value will be a datetime object. I think this can be handled the same way as when format=None.

This would allow simplifying the whole thing as follows:

try: format = field._field.format except AttributeError: format = api_settings.DATETIME_FORMAT if format is None: # field.value is a datetime # https://www.django-rest-framework.org/api-guide/fields/#datetimefield datetime_field_value = field.value else: # field.value is expected to be a string datetime_field_value = datetime.datetime.strptime(field.value, format)

Also, the comment in line 342 is misleading (not your fault): .as_form_field() only transforms None and False into textual representations, but not datetime objects. Perhaps you can fix that comment to just say "Get a clone of the field that properly deals with None value" or something?

Thank you peter, thanks for your patience! 🙏

I've added a new test with DATETIME_FORMAT as None and no format defined.

I updated the .as_form_field() but trying to keep it as it is, just adding the example you mentioned.

I've used your code suggestion + adding the corresponding formatting in case of ISO_8601 string.

Thank you peter, thanks for your patience! 🙏

Thank you for your patience! Always easy to make comments from the side lines, as I'm doing :p

I've added a new test with DATETIME_FORMAT as None and no format defined.

Great.

I've used your code suggestion + adding the corresponding formatting in case of ISO_8601 string.

Ah of course, had overlooked that.

Now I realize this can be further simplified by getting rid of datetime_field_value:

try: format = field._field.format except AttributeError: format = api_settings.DATETIME_FORMAT if format is not None: # field.value is expected to be a string, see DateTimeField docs field.value = ( datetime.datetime.fromisoformat(field.value.rstrip('Z')) if format == ISO_8601 else datetime.datetime.strptime(field.value, format) ) # The format of an input type="datetime-local" is "yyyy-MM-ddThh:mm" # followed by optional ":ss" or ":ss.SSS", so keep only the first three # digits of milliseconds to avoid browser console error. field.value = field.value.replace(tzinfo=None).isoformat(timespec="milliseconds")

mgaligniana · 2025-10-15T13:26:59Z

Also, the tests have quite some code duplication (I'm not sure if that is a problem).

Yes!! Of course, I can improve that!

mgaligniana · 2025-10-16T01:21:55Z

Also, the tests have quite some code duplication (I'm not sure if that is a problem).

Yes!! Of course, I can improve that!

Tests are prettier now! (I hope so)

peterthomassen · 2025-10-17T07:23:30Z

tests/test_renderers.py

+        field = serializer['appointment']
+        rendered = renderer.render_field(field, {})
+        expected_html = (
+            f'<input name="appointment" class="form-control" '


f prefix unnecessary

peterthomassen · 2025-10-17T07:24:35Z

tests/test_renderers.py

+            f'type="datetime-local" value="{expected}">'
+        )
+
+        self.assertInHTML(expected_html, rendered)


Do we really mean assertInHTML, or would the somewhat stricter assertHTMLEqual work as well?

peterthomassen · 2025-10-17T07:25:18Z

tests/test_renderers.py

+    def test_datetime_field_rendering_no_milliseconds(self):
+        self._assert_datetime_rendering(
+            datetime(2024, 12, 24, 0, 55, 30, 0), "2024-12-24T00:55:30.000"
+        )


I think this one is redundant as test_datetime_field_rendering_no_seconds_and_no_milliseconds covers it as well.

auvipy self-requested a review May 27, 2024 16:08

auvipy requested a review from a team June 10, 2024 07:08

peterthomassen requested changes Jun 10, 2024

View reviewed changes

rest_framework/renderers.py Outdated Show resolved Hide resolved

stale bot added the stale label Apr 27, 2025

auvipy reviewed Apr 28, 2025

View reviewed changes

stale bot removed the stale label Apr 28, 2025

deepakangadi reviewed Jul 25, 2025

View reviewed changes

tests/test_renderers.py Outdated Show resolved Hide resolved

mgaligniana force-pushed the issue-5363 branch from c967a6f to 29e41f1 Compare July 26, 2025 13:19

mgaligniana requested a review from auvipy July 30, 2025 14:58

auvipy requested a review from Copilot August 16, 2025 09:33

Copilot AI reviewed Aug 16, 2025

View reviewed changes

rest_framework/renderers.py Outdated Show resolved Hide resolved

tests/test_renderers.py Outdated Show resolved Hide resolved

mgaligniana requested a review from peterthomassen August 17, 2025 20:57

auvipy previously approved these changes Aug 18, 2025

View reviewed changes

peterthomassen reviewed Aug 19, 2025

View reviewed changes

auvipy self-requested a review August 20, 2025 14:07

mgaligniana commented Aug 21, 2025

View reviewed changes

rest_framework/renderers.py Outdated Show resolved Hide resolved

mgaligniana force-pushed the issue-5363 branch 2 times, most recently from 6d5cff3 to 0c2b20c Compare August 21, 2025 04:12

browniebroke reviewed Aug 21, 2025

View reviewed changes

mgaligniana force-pushed the issue-5363 branch from 617f876 to 34db0cb Compare September 7, 2025 17:10

auvipy requested a review from Copilot September 21, 2025 05:10

Copilot AI reviewed Sep 21, 2025

View reviewed changes

rest_framework/renderers.py Outdated Show resolved Hide resolved

mgaligniana and others added 5 commits October 14, 2025 22:51

Fixed encode#5363 -- HTML5 datetime-local valid format HTMLFormRenderer

a09161e

Update tests/test_renderers.py

db970e2

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Apply changes requested by peterthomassen

68c0850

Use datetime value to render datetime-local input_type

a618758

Add test for HTMLFormRenderer when is UTC

78e87f8

mgaligniana force-pushed the issue-5363 branch 3 times, most recently from bce2aa2 to fee4af2 Compare October 15, 2025 02:31

mgaligniana requested a review from Copilot October 15, 2025 02:35

Copilot AI reviewed Oct 15, 2025

View reviewed changes

rest_framework/renderers.py Outdated Show resolved Hide resolved

rest_framework/renderers.py Outdated Show resolved Hide resolved

rest_framework/renderers.py Outdated Show resolved Hide resolved

mgaligniana force-pushed the issue-5363 branch from fee4af2 to d894aab Compare October 15, 2025 03:12

Add better approach

a15dfb4

mgaligniana force-pushed the issue-5363 branch from d894aab to a15dfb4 Compare October 15, 2025 03:23

peterthomassen reviewed Oct 15, 2025

View reviewed changes

Apply changes suggested by peterthomassen

2bad745

Apply changes suggested by peterthomassen (conditionals + test)

85b4d34

peterthomassen reviewed Oct 17, 2025

View reviewed changes

		assert rendered == ''


		class TestDateTimeFieldHTMLFormRender(TestCase):

Uh oh!

Fixed #5363 -- HTML5 datetime-local valid format HTMLFormRenderer #9365

Are you sure you want to change the base?

Fixed #5363 -- HTML5 datetime-local valid format HTMLFormRenderer #9365

Conversation

mgaligniana commented Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

mgaligniana commented May 27, 2024

Uh oh!

Uh oh!

stale bot commented Apr 27, 2025

Uh oh!

auvipy left a comment

Choose a reason for hiding this comment

Uh oh!

mgaligniana commented Apr 28, 2025

Uh oh!

mgaligniana commented Jun 10, 2025

Uh oh!

Uh oh!

mgaligniana commented Jul 26, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

peterthomassen left a comment

Choose a reason for hiding this comment

Uh oh!

mgaligniana commented Aug 19, 2025

Uh oh!

peterthomassen commented Aug 19, 2025

Uh oh!

browniebroke commented Aug 20, 2025

Uh oh!

mgaligniana commented Aug 20, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgaligniana Sep 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgaligniana commented Aug 21, 2025

Uh oh!

mgaligniana commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mgaligniana commented Oct 15, 2025

Uh oh!

peterthomassen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mgaligniana commented Apr 4, 2024 •

edited

Loading

mgaligniana Sep 7, 2025 •

edited

Loading

mgaligniana commented Sep 18, 2025 •

edited

Loading

peterthomassen Oct 16, 2025 •

edited

Loading

mgaligniana Oct 17, 2025 •

edited

Loading

mgaligniana commented Oct 16, 2025 •

edited

Loading