Truncation of microseconds in DateTimeField leads to lookup trouble

[Piotr Maliński]

I've stumbled upon an yet another inconsistency in Django forms with microseconds handling.

I have a model with DateTime field set with timezone.now(). In a form this date is passed as hidden so that before save it can be verified that the content didn't changed during moderation. The problem is that timezone.now() sets microseconds, while datetime returned in form_valid is without microseconds and thus can't be used for direct lookup on that model field (and that what hurts).

[Tim Graham]

I guess ​this is the offending code.

[Claude Paroz]

It might be a use case for the supports_microseconds widget property (which needs documentation, by the way).

Could you try to subclass HiddenInput, set supports_microseconds class attribute to True for your subclass, and then use that widget in your form?

[Baptiste Mispelon]

Documentation issue tracked in #24520.

[Piotr Maliński]

Replying to claudep:

It might be a use case for the supports_microseconds widget property (which needs documentation, by the way).

Could you try to subclass HiddenInput, set supports_microseconds class attribute to True for your subclass, and then use that widget in your form?

Depends what should be the default behavior for a ModelForm? Field in a model should be tailored to a matching form field and it validation rules. If Django must permanently modify DatetTimes for display and alike purposes then it should be explicit and consistent with models. If form field has supports_microseconds then maybe DateTimeField in a model should also have such attribute so that setting timezone.now()/datetime.now() etc. won't save with microseconds in the first place?

[wdmgsm]

It was suggested by bmispelon in this ​pull request to add supports_microseconds to the base Widget class so that all derived widgets inherit it.

[Tim Graham]

​PR

[Tim Graham <timograham@…>]

In 4dcc649:

Fixed #24497 -- Added Widget.supports_microseconds attribute