I see, I'll switch to djblets' JSONFormField. I added the clean_extra_data method because I saw it in some other forms that have an extra data field. Once I add some more tests I'll check if I actually need it and get rid of it accordingly.

Got it. I am however confused on what you mean about the Date/time fields. Could you give some examples of what the data would look like to test this?

Sure, so for Django-based JSON support (both in Django's and Djblet's), there's a Serializer class that takes in data (primitive JSON-compatible data along with some other Python types, like datetime) and converts it to JSON. datetime becomes a ISO8601 string, since JSON lacks a date/time type. But, for historical reasons (having to do with older Django behavior and limitations in some databases), we end up formatting that string differently (stripping milliseconds from the results). I don't believe Django does that anymore, which means there'd be a different result if using their JSON field stuff vs. ours.

Ok, I've updated the tests but I'm only setting extra_data to a dictionary or a JSON string of a dictionary. There are no tests where I set extra_data to a datetime object, since it doesn't make sense to have our extra_data set to anything other than a dictionary (right?). When I include a datetime object in the extra_data dictionary that I pass to the form, and then access it from the file_attachment.extra_data, I just get a datetime object and not an ISO8601 string.

extra_data should be a dictionary in all cases, but you can fill that with keys for different data types.
Since extra_data is really just a dictionary, anything you store will be retained as-is until you load back from the database. At that point, you should see a string for the datetime.