As further follow up on this, as far as I can tell, the relevant unit test does not run, seemingly due to the use of `translation.override(None)`
Removing, that, and running the test `./runtests.py forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField` results in the test failing. Arthur Pemberton On Sunday, December 8, 2024 at 8:03:22 PM UTC-5 Arthur Pemberton wrote: To simplify things further, within a view: TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p'] and forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton <pem...@gmail.com> wrote: I finally got back to this. I have a failing minimal project (not test) that demonstrates TIME_INPUT_FORMATS not being respected: https://github.com/pembo13/dateentry In the example, the form should be valid, if TIME_INPUT_FORMATS worked as documented. I _think_ there's something about how the unittest is written that allows it to pass, and not expose this. Regards, Arthur On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson <m...@adamj.eu> wrote: USE_I18N does not disable localization, but internationalization. USE_L10N was the setting to enable/disable localization, but it was deprecated in Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was removed completely in Django 5.0, in this commit: https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470 . So I think the phrase “if localization is disabled” is at least a little bit wrong. But I don’t think the setting is ignored, as there are tests confirming that it works: https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125 . The line that reads the setting should be this one: https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132 . If you can provide a failing minimal project, that would be useful to keep debugging. I have some minimal django project templates at https://github.com/adamchainz/django-startproject-templates . On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote: Thanks, I'll look into that. But does that mean that settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic flows that lead to it being used. On Tue, Mar 5, 2024 at 3:00 AM David Sanders <shang.xia...@gmail.com> wrote: Define TIME_INPUT_FORMATS in your local formats.py setup as per: https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton <pem...@gmail.com> wrote: The documentation ( https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says that " the default input formats are taken from the active locale format TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS> if localization is disabled". However, neither my reading of the code, or my actual experience shows settings.TIME_INPUT_FORMATS ever being used, even with "USE_I18N = False" TimeField gets the formats from `input_formats = formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of `formats.get_format` -- the documentation of which says "If use_l10n is provided and is not None, it forces the value to be localized (or not), otherwise it's always localized." so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be ignored. How does one use settings.TIME_INPUT_FORMATS ? Arthur Pemberton -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ87df%2B8-Rq5LbpLcctp9jNfjA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ87df%2B8-Rq5LbpLcctp9jNfjA%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/django-developers/2525be1c-e2a7-4080-81c5-ef6e2ba0eec3n%40googlegroups.com.
