settings.TIME_INPUT_FORMATS never gets used since the removal of USE_L10N

[Arthur Pemberton]

forms.TimeField references TIME_INPUT_FORMATS via a call to django.utils.formats.get_format(). However since the removal of settings.USE_L10N(​https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470) if get_format() is called without its use_l10n parameter, it defaults to True, as is the case with forms.TimeField. So locale specific TIME_INPUT_FORMATS is always used.

This technically matches the documentation: "If no input_formats argument is provided, the default input formats are taken from the active locale format TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS". However, the implication is that settings.TIME_INPUT_FORMATS is used if you're not using localization -- but it's no longer possible to turn off localization.

Also, due to ticket:35986 the unittests covering this has likely not been running.

[Sarah Boyce]

I think the point you're trying to make would be the same for DATE_INPUT_FORMATS
If I update the tests from having the @translation.override(None) class level to having it decorate each test, the tests pass
So currently these are used if the translation is missing the format.

Closing as I think this is currently by design and appears to be documented
If we want changes, this might be a topic to raise on the ​forum.

Refs #32873

[Arthur Pemberton]

What is the equivalent of @translation.override(None) in a practical scenario (ie. outside of unit test)? How do I use settings.TIME_INPUT_FORMATS or is the only way to implement locale modules for the locale matching LANGUAGE_CODE

[Sarah Boyce]

Use a language that doesn't have TIME_INPUT_FORMATS set, like bg. The formats.py file will have # TIME_INPUT_FORMATS =