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

Clarify TIME_ZONE documentation - why is UTC recommended? #8502

New Issue
Closed
opened 2025-12-29 20:37:30 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:37:30 +01:00
Owner
Copy Link

Originally created by @pv2b on GitHub (Aug 23, 2023).

Change Type

Removal

Area

Configuration

Proposed Changes

The current documentation for the TIME_ZONE configuration parameter reads:

TIME_ZONE

Default: UTC

The time zone NetBox will use when dealing with dates and times. It is recommended to use UTC time unless you have a specific need to use a local time zone. Please see the list of available time zones.

Let's go focus on this sentence:

It is recommended to use UTC time unless you have a specific need to use a local time zone.

This is far too vague. As a reader, I'm not sure why this recommendation exists, or why it's a good idea. Reading between the lines, I'm left wondering, is it maybe "recommended" to use UTC because there are some unspecified or unknown bugs that might happen, or some weird side effects? (Also see #13531, it's not clear what "dealing with" means in this context.)

My guess as to what's going on here is that Netbox is trying to encourage administrators towards a best practice of using UTC for display time. It's certainly a legitimate opinion that using UTC for display everywhere makes communication between team members easier, and provides a common frame of reference unaffected by Daylight Savings Time, especially spanning multiple time zones.

Another reason why UTC might be a good idea for Netbox specifically, is that Netbox currently doesn't allow user-specific time display options, so if you have a timezone-distributed organization, setting a specific timezone for everyone's a pretty bad idea.

In my opinion, the Netbox documentation isn't really the place to be making best-practices recommendations for how organizations should approach internally communicating times and dates, so in my opinion, this sentence should be removed from the documentation, so that users aren't discouraged from making the choice that's right for their org by a vague "don't do that".

The other option is to write up a paragraph explaining why UTC is recommended, or linking to some outside article on that subject. Or even just mention that if you have team members in different timezones that, because Netbox can't do user-specific timezones currently, keeping it to UTC will be your best option to keep things neutral.

In my case, my org is completely based in one time zone, and we don't use UTC under normal circumstances, so setting display time to local time makes the most sense for us in our current culture. (And changing it shouldn't be within the scope of adopting Netbox, specifically.)

Originally created by @pv2b on GitHub (Aug 23, 2023). ### Change Type Removal ### Area Configuration ### Proposed Changes The [current documentation](https://demo.netbox.dev/static/docs/configuration/optional-settings/#time_zone) for the `TIME_ZONE` configuration parameter reads: > TIME_ZONE > > Default: UTC > > The time zone NetBox will use when dealing with dates and times. It is recommended to use UTC time unless you have a specific need to use a local time zone. Please see the [list of available time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Let's go focus on this sentence: > It is recommended to use UTC time unless you have a specific need to use a local time zone. This is far too vague. As a reader, I'm not sure why this recommendation exists, or why it's a good idea. Reading between the lines, I'm left wondering, is it maybe "recommended" to use UTC because there are some unspecified or unknown bugs that might happen, or some weird side effects? (Also see #13531, it's not clear what "dealing with" means in this context.) My *guess* as to what's going on here is that Netbox is trying to encourage administrators towards a best practice of using UTC for display time. It's certainly a legitimate opinion that using UTC for display everywhere makes communication between team members easier, and provides a common frame of reference unaffected by Daylight Savings Time, especially spanning multiple time zones. Another reason why UTC might be a good idea for Netbox specifically, is that Netbox currently doesn't allow user-specific time display options, so if you have a timezone-distributed organization, setting a specific timezone for everyone's a pretty bad idea. In my opinion, the Netbox documentation isn't really the place to be making best-practices recommendations for how organizations should approach internally communicating times and dates, so in my opinion, this sentence should be removed from the documentation, so that users aren't discouraged from making the choice that's right for their org by a vague "don't do that". The other option is to write up a paragraph explaining *why* UTC is recommended, or linking to some outside article on that subject. Or even just mention that if you have team members in different timezones that, because Netbox can't do user-specific timezones currently, keeping it to UTC will be your best option to keep things neutral. In my case, my org is completely based in one time zone, and we don't use UTC under normal circumstances, so setting display time to local time makes the most sense for us in our current culture. (And changing it shouldn't be within the scope of adopting Netbox, specifically.)
adam added the type: documentation label 2025-12-29 20:37:30 +01:00
adam closed this issue 2025-12-29 20:37:30 +01:00
adam commented 2025-12-29 20:37:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 23, 2023):

The consistent use of UTC is considered best practice in the industry. An explanation behind it is out of scope for the NetBox documentation. If you have a reason to use a different time zone, use that.

@jeremystretch commented on GitHub (Aug 23, 2023): The consistent use of UTC is considered best practice in the industry. An explanation behind it is out of scope for the NetBox documentation. If you have a reason to use a different time zone, use that.
adam commented 2025-12-29 20:37:31 +01:00
Author
Owner
Copy Link

@pv2b commented on GitHub (Aug 23, 2023):

The consistent use of UTC is considered best practice in the industry. An explanation behind it is out of scope for the NetBox documentation. If you have a reason to use a different time zone, use that.

I agree, and to clarify, that is why my primary suggestion was to compeltely remove the recommendation to use UTC. As written right now, it's possible to misunderstand the documentation as a warning that some Netbox functionality might be negatively impacted by changing the setting. Best to remove the sentence altogether.

@pv2b commented on GitHub (Aug 23, 2023): > The consistent use of UTC is considered best practice in the industry. An explanation behind it is out of scope for the NetBox documentation. If you have a reason to use a different time zone, use that. I agree, and to clarify, that is why my primary suggestion was to compeltely remove the recommendation to use UTC. As written right now, it's possible to misunderstand the documentation as a warning that some Netbox functionality might be negatively impacted by changing the setting. Best to remove the sentence altogether.
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 type: documentation
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#8502
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?