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

TimeZone Validation Error when bulk-editing sites #1951

New Issue
Closed
opened 2025-12-29 17:20:52 +01:00 by adam · 7 comments
adam commented 2025-12-29 17:20:52 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (Aug 17, 2018).

Environment

  • Python version: 3.6
  • NetBox version: 2.4.3

Steps to Reproduce

I'm not sure exactly how this happened, but the time_zone of a certain number of sites are really messed up in my production instance of NetBox.

It appears to only be an issue where, the offset is NOT on the even hour mark (i.e. UTC +05:30 in India).
When I try to bulk-edit an unrelated custom_field, I get the following error:

timezone error

However, when I view that site, everything appears to be normal:

timezone error 2

Only after clicking Edit and not changing anything and then clicking Save and re-trying the bulk-edit I was attempting before, does the problem go away.

Expected Behavior

To NOT see a TimeZone validation error when the WebUI appears to be okay.

Observed Behavior

The validation error seems to include an additional 53 minutes to the timezone no matter what until after the site is individually edited and saved.

I'm going to proceed and keep fixing my production instance of NetBox so I mostly likely won't have an option to follow-up on this should you require more information. I'll try and get a backup of my postgres database to which contains these errors, but I don't know if that will help at all.

Here's another example of a different site in India:

timezone error 3

Showing the individual site:

timezone error 4

Originally created by @bdlamprecht on GitHub (Aug 17, 2018). ### Environment * Python version: 3.6 * NetBox version: 2.4.3 ### Steps to Reproduce I'm not sure *exactly* how this happened, but the `time_zone` of a certain number of `sites` are really messed up in my production instance of NetBox. --- It _appears_ to only be an issue where, the offset is *NOT* on the even hour mark (i.e. `UTC +05:30` in India). When I try to bulk-edit an unrelated `custom_field`, I get the following error: ![timezone error](https://user-images.githubusercontent.com/7783306/44279238-df558b00-a20d-11e8-9bbf-6093b95c5f57.JPG) --- However, when I view that site, everything _appears_ to be normal: ![timezone error 2](https://user-images.githubusercontent.com/7783306/44279280-0d3acf80-a20e-11e8-97d1-3128852754d0.JPG) --- Only after clicking `Edit` and not changing *anything* and then clicking `Save` and re-trying the bulk-edit I was attempting before, does the problem go away. ### Expected Behavior To *NOT* see a `TimeZone` validation error when the WebUI appears to be okay. ### Observed Behavior The validation error seems to include an additional `53` minutes to the timezone no matter what until after the site is individually edited and saved. I'm going to proceed and keep fixing my production instance of NetBox so I mostly likely won't have an option to follow-up on this should you require more information. I'll try and get a backup of my `postgres` database to which contains these errors, but I don't know if that will help at all. --- Here's another example of a different site in India: ![timezone error 3](https://user-images.githubusercontent.com/7783306/44279674-7e2eb700-a20f-11e8-831e-d190514f6765.JPG) Showing the individual site: ![timezone error 4](https://user-images.githubusercontent.com/7783306/44279712-a74f4780-a20f-11e8-9224-a9940d37c5bd.JPG)
adam added the type: bugstatus: accepted labels 2025-12-29 17:20:52 +01:00
adam closed this issue 2025-12-29 17:20:52 +01:00
adam commented 2025-12-29 17:20:52 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 17, 2018):

I just found another site where the offset was NOT on the 30 minute mark UTC +0700:

timezone error 5

And the individual site:

timezone error 6

The timezone in the error is off by 7 minutes instead of 53 like before, so there is definately some strange math going on internally that is wrong.

@bdlamprecht commented on GitHub (Aug 17, 2018): I just found another site where the offset was **NOT** on the 30 minute mark `UTC +0700`: ![timezone error 5](https://user-images.githubusercontent.com/7783306/44280208-46c10a00-a211-11e8-8b5d-e5e2eecca80f.JPG) And the individual site: ![timezone error 6](https://user-images.githubusercontent.com/7783306/44280231-5c363400-a211-11e8-94cf-c900dc0a39d0.JPG) The timezone in the error is off by `7` minutes instead of `53` like before, so there is definately some strange math going on internally that is wrong.
adam commented 2025-12-29 17:20:53 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 17, 2018):

Here another odd error (-1 day?):

timezone error 7

timezone error 8

@bdlamprecht commented on GitHub (Aug 17, 2018): Here another odd error (`-1 day`?): ![timezone error 7](https://user-images.githubusercontent.com/7783306/44280532-470dd500-a212-11e8-8940-c4e52805e74a.JPG) ![timezone error 8](https://user-images.githubusercontent.com/7783306/44280536-4aa15c00-a212-11e8-9832-ddaa63de6345.JPG)
adam commented 2025-12-29 17:20:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 17, 2018):

So after a bit of poking, it seems that the root issue is that django-timezone-field restricts the choices for this field to the timezones included in the set pytz.common_timezones. The API field serializer, however, will accept any string which pytz considers a valid timezone (i.e. pytz.all_timezones).

I don't want to inherit the problem of maintaining timezones. Really, I can't overstate how much I'd like to avoid that. So we have two options:

  1. Tweak the API serializer to only accept values within pytz.common_timezones.
  2. Initialize TimeZoneField so that all of pytz.all_timezones are valid choices.

I don't have a strong opinion, although it's worth noting that all_timezones is a considerably larger set:

>>> len(pytz.common_timezones)
439
>>> len(pytz.all_timezones)
591
@jeremystretch commented on GitHub (Aug 17, 2018): So after a bit of poking, it seems that the root issue is that `django-timezone-field` restricts the choices for this field to the timezones included in the set `pytz.common_timezones`. The API field serializer, however, will accept _any_ string which `pytz` considers a valid timezone (i.e. `pytz.all_timezones`). I don't want to inherit the problem of maintaining timezones. Really, I can't overstate how much I'd like to avoid that. So we have two options: 1. Tweak the API serializer to only accept values within `pytz.common_timezones`. 2. Initialize TimeZoneField so that all of `pytz.all_timezones` are valid choices. I don't have a strong opinion, although it's worth noting that `all_timezones` is a considerably larger set: ``` >>> len(pytz.common_timezones) 439 >>> len(pytz.all_timezones) 591 ```
adam commented 2025-12-29 17:20:53 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 17, 2018):

I agree with this comment:

I don't want to inherit the problem of maintaining time-zones. Really, I can't overstate how much I'd like to avoid that.

Concerning the options you outlined above, I'd personally prefer doing option #2 as py.all_timezones appears to include "odd" ones that I'm currently using.

However, it you do choose option #1, I'll deal with it as I don't want to place my problems of getting accurate data from my customer (😬) on the NetBox project and make it less desirable for the community as a whole.

All that being said, I don't know how much of a burden of an additional 152 time zones is (~34% of the current total)?

@bdlamprecht commented on GitHub (Aug 17, 2018): I agree with this comment: > I don't want to inherit the problem of maintaining time-zones. Really, I can't overstate how much I'd like to avoid that. Concerning the options you outlined above, I'd personally prefer doing option `#2` as `py.all_timezones` appears to include "odd" ones that I'm currently using. However, it you do choose option `#1`, I'll deal with it as I don't want to place my problems of getting accurate data from my customer (:grimacing:) on the NetBox project and make it less desirable for the community as a whole. All that being said, I don't know how much of a burden of an additional 152 time zones is (~34% of the current total)?
adam commented 2025-12-29 17:20:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 17, 2018):

Here's the delta of additional timezones. Some of them seem a bit confusing. For example, GMT+0, GMT-0, and GMT0 are all choices. Also there are items like Singapore, which is presumably a duplicate (but maybe not) of Asia/Singapore.

@jeremystretch commented on GitHub (Aug 17, 2018): [Here's the delta](https://gist.github.com/jeremystretch/3d77aa7615f03ec1da658336e48be137) of additional timezones. Some of them seem a bit confusing. For example, `GMT+0`, `GMT-0`, and `GMT0` are all choices. Also there are items like `Singapore`, which is presumably a duplicate (but maybe not) of `Asia/Singapore`.
adam commented 2025-12-29 17:20:54 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 17, 2018):

I think it would be beneficial to include these additional entries to as to not be too restrictive on end-users.

@bdlamprecht commented on GitHub (Aug 17, 2018): I think it would be beneficial to include these additional entries to as to not be too restrictive on end-users.
adam commented 2025-12-29 17:20:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 20, 2018):

I'm just going to limit the serializer to accept only values from within pytz.common_timezones for now. I'd also like to organize the timezones by country to make the list a bit more user-friendly. Maybe we can revisit expanding the list once that's in place.

@jeremystretch commented on GitHub (Aug 20, 2018): I'm just going to limit the serializer to accept only values from within `pytz.common_timezones` for now. I'd also like to organize the timezones by country to make the list a bit more user-friendly. Maybe we can revisit expanding the list once that's in place.
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#1951
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?