In order to fix this, we would need to somehow distinguish whether a DateTimeField is implemented in the database as a DATE or TIMESTAMP column. I can see two ways of doing this:

By doing automatic introspection on every DateTimeField at start-up in order to determine the actual column types. This would be quite a bit heavier than the introspection we currently do, and it doesn't seem very practical to me.

By adding a precision keyword argument to DateTimeField and TimeField that denotes the fractional second precision to be used. This might be a worthwhile feature to add, but it's outside the scope of this ticket.

Also, there are a full complement of workarounds here. Either use a DateField with a DATE column, or a DateTimeField with a TIMESTAMP column, or if you really need to mix and match, turn off auto_now and use a pre_save signal to manually set the field with the correct precision.

So my conclusion is that the proper response to this for now is "don't do that", and I'm closing this as wontfix.