starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Wrong date format #7357

New Issue
Closed
opened 2025-12-29 20:22:16 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:22:16 +01:00
Owner
Copy Link

Originally created by @fixed77 on GitHub (Dec 15, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.4.0

Python version

3.8

Steps to Reproduce

  1. Set date format in configuration.py
SHORT_DATE_FORMAT = 'Y-m-d'
TIME_FORMAT = 'H:i'
SHORT_TIME_FORMAT = 'H:i:s'
DATETIME_FORMAT = 'j N Y H:i'
SHORT_DATETIME_FORMAT = 'Y-m-d H:i'
  1. Restart netbox
  2. In main page after login date in bottom: 12/15/2022 11:11 a.m.
  3. Other -> Change Log. Open any record. Time: 12/15/2022 10:22 a.m.
  4. Open any Virtual machine. Created 01/26/2022 3 a.m. · Updated 1 month, 1 week ago (Without minutes)

Expected Behavior

Expected date format as specified in configuration.py

Observed Behavior

Observed wrong date format

Originally created by @fixed77 on GitHub (Dec 15, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.4.0 ### Python version 3.8 ### Steps to Reproduce 1. Set date format in configuration.py ```DATE_FORMAT = 'j N Y' SHORT_DATE_FORMAT = 'Y-m-d' TIME_FORMAT = 'H:i' SHORT_TIME_FORMAT = 'H:i:s' DATETIME_FORMAT = 'j N Y H:i' SHORT_DATETIME_FORMAT = 'Y-m-d H:i' ``` 2. Restart netbox 3. In main page after login date in bottom: `12/15/2022 11:11 a.m. ` 4. Other -> Change Log. Open any record. `Time: 12/15/2022 10:22 a.m.` 5. Open any Virtual machine. `Created 01/26/2022 3 a.m. · Updated 1 month, 1 week ago` (Without minutes) ### Expected Behavior Expected date format as specified in configuration.py ### Observed Behavior Observed wrong date format
adam added the type: bugstatus: accepted labels 2025-12-29 20:22:16 +01:00
adam closed this issue 2025-12-29 20:22:16 +01:00
adam commented 2025-12-29 20:22:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 15, 2022):

Observed wrong date format

The date and time are being formatted according to the locale specified by your browser. Automatic localization was enabled in NetBox v3.4 (see #10821), and the configured formats are now used only as fallbacks. This ensures that dates and times are presented to each user in their "native" format according to locale. (The option to disable localization is being removed in Django 5.0 entirely.)

@jeremystretch commented on GitHub (Dec 15, 2022): > Observed wrong date format The date and time are being formatted according to the locale specified by your browser. Automatic localization was enabled in NetBox v3.4 (see #10821), and the configured formats are now used only as fallbacks. This ensures that dates and times are presented to each user in their "native" format according to locale. (The option to _disable_ localization is being [removed in Django 5.0](https://docs.djangoproject.com/en/4.1/ref/settings/#std-setting-USE_L10N) entirely.)
adam commented 2025-12-29 20:22:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 15, 2022):

Seems that we have the option of "unlocalizing" specific date/time strings in templates. This might be appropriate in some places, but in general we probably want to stick to localized formats.

@jeremystretch commented on GitHub (Dec 15, 2022): Seems that we have the option of "[unlocalizing](https://docs.djangoproject.com/en/4.1/topics/i18n/formatting/#unlocalize)" specific date/time strings in templates. This might be appropriate in some places, but in general we probably want to stick to localized formats.
adam commented 2025-12-29 20:22:17 +01:00
Author
Owner
Copy Link

@fixed77 commented on GitHub (Dec 15, 2022):

Observed wrong date format

The date and time are being formatted according to the locale specified by your browser. Automatic localization was enabled in NetBox v3.4 (see #10821), and the configured formats are now used only as fallbacks. This ensures that dates and times are presented to each user in their "native" format according to locale. (The option to disable localization is being removed in Django 5.0 entirely.)

Then it doesn't seem to work properly.

@fixed77 commented on GitHub (Dec 15, 2022): > > Observed wrong date format > > The date and time are being formatted according to the locale specified by your browser. Automatic localization was enabled in NetBox v3.4 (see #10821), and the configured formats are now used only as fallbacks. This ensures that dates and times are presented to each user in their "native" format according to locale. (The option to _disable_ localization is being [removed in Django 5.0](https://docs.djangoproject.com/en/4.1/ref/settings/#std-setting-USE_L10N) entirely.) Then it doesn't seem to work properly.
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@fixed77 commented on GitHub (Dec 15, 2022):

I trying open netbox with Firefox and Chrome, change locale in DevTools, but unfortunately no success.

@fixed77 commented on GitHub (Dec 15, 2022): I trying open netbox with Firefox and Chrome, change locale in DevTools, but unfortunately no success.
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@fixed77 commented on GitHub (Dec 16, 2022):

fixed by returning to settings.py:

USE_I18N = True
USE_L10N = False
@fixed77 commented on GitHub (Dec 16, 2022): fixed by returning to settings.py: ``` USE_I18N = True USE_L10N = False ```
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 16, 2022):

@jeremystretch - Found the issue I think, haven't tested though. According to the documentation, we need to activate the django.middleware.locale.LocaleMiddleware to support automatic localization. Otherwise the fallback is LANGUAGE_CODE for all users.

It might also be nice to expose LANGUAGE_CODE as a configuration value for fallback, and maybe even allow disabling the LocaleMiddleware to provide static localization.

@kkthxbye-code commented on GitHub (Dec 16, 2022): @jeremystretch - Found the issue I think, haven't tested though. According to [the documentation](https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#how-django-discovers-language-preference), we need to activate the `django.middleware.locale.LocaleMiddleware` to support automatic localization. Otherwise the fallback is [LANGUAGE_CODE](https://github.com/netbox-community/netbox/blob/develop/netbox/netbox/settings.py#LL389) for all users. It might also be nice to expose LANGUAGE_CODE as a configuration value for fallback, and maybe even allow disabling the LocaleMiddleware to provide static localization.
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 16, 2022):

According to the documentation, we need to activate the django.middleware.locale.LocaleMiddleware to support automatic localization.

Ah, good catch! I forgot we had removed that from the middleware list.

It might also be nice to expose LANGUAGE_CODE as a configuration value for fallback

We can do this, though I worry it might be a bit confusing given that NetBox doesn't actually support different languages (although we've started tracking that work under #10833). We'll just have to be clear about its effect. I've opened #11214 for this.

@jeremystretch commented on GitHub (Dec 16, 2022): > According to [the documentation](https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#how-django-discovers-language-preference), we need to activate the django.middleware.locale.LocaleMiddleware to support automatic localization. Ah, good catch! I forgot we had removed that from the middleware list. > It might also be nice to expose LANGUAGE_CODE as a configuration value for fallback We can do this, though I worry it might be a bit confusing given that NetBox doesn't actually support different languages (although we've started tracking that work under #10833). We'll just have to be clear about its effect. I've opened #11214 for this.
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@Alef-Burzmali commented on GitHub (Dec 17, 2022):

I don't feel this bug is fixed, as there is no way to have nice and non-ambiguous date formats like ISO 8601 like previously, instead I am stuck with whatever my browser's preferred language is for browsing and what Django's think would be best for that.

Is there currently a way to make the various DATE_FORMAT, SHORT_DATE_FORMAT, etc. the winning settings again? Or would that require a new setting/user preference?

@Alef-Burzmali commented on GitHub (Dec 17, 2022): I don't feel this bug is fixed, as there is no way to have nice and non-ambiguous date formats like ISO 8601 like previously, instead I am stuck with whatever my browser's preferred language is for browsing and what Django's think would be best for that. Is there currently a way to make the various DATE_FORMAT, SHORT_DATE_FORMAT, etc. the winning settings again? Or would that require a new setting/user preference?
adam commented 2025-12-29 20:22:18 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 17, 2022):

@Alef-Burzmali - I agree, it's not optimal. Django however does not make it easy when USE_L10N is True, and as Jeremy said that setting is going away.

As far as I can tell the correct way to specify custom localization when localization is enabled, is to use FORMAT_MODULE_PATH as described here:

https://docs.djangoproject.com/en/4.1/ref/settings/#format-module-path

It's just terrible user experience to have to set that variable, create the specific folder structure for any language your users might use and then changing all the individual settings.

Another issue is that for me with danish language set in Chrome, I get weird stuff like this:
image

So years and months are translated to danish, but updated and ago are not.

Do you have any ideas here @jeremystretch - can we maybe revert it until we find a better solution? We still have a year until Django 5.0 (December 2023).

Another personal issue is that I usually set my browser language set to English (UK) as Danish translations are most often terrible, so with the new change I'm stuck with AM/PM datetimes. As far as I can tell there's no browser header to specify wanting English language but Danish localization.

@kkthxbye-code commented on GitHub (Dec 17, 2022): @Alef-Burzmali - I agree, it's not optimal. Django however does not make it easy when USE_L10N is True, and as Jeremy said that setting is going away. As far as I can tell the correct way to specify custom localization when localization is enabled, is to use `FORMAT_MODULE_PATH` as described here: https://docs.djangoproject.com/en/4.1/ref/settings/#format-module-path It's just terrible user experience to have to set that variable, create the specific folder structure for any language your users might use and then changing all the individual settings. Another issue is that for me with danish language set in Chrome, I get weird stuff like this: ![image](https://user-images.githubusercontent.com/400797/208251638-daf2fa9e-6f87-40b6-af5a-b77c10968f65.png) So years and months are translated to danish, but `updated` and `ago` are not. Do you have any ideas here @jeremystretch - can we maybe revert it until we find a better solution? We still have a year until Django 5.0 (December 2023). Another personal issue is that I usually set my browser language set to English (UK) as Danish translations are most often terrible, so with the new change I'm stuck with AM/PM datetimes. As far as I can tell there's no browser header to specify wanting English language but Danish localization.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7357
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?