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

format of date_time custom fields through the REST API on GET are not compatible with POST #8691

New Issue
Closed
opened 2025-12-29 20:39:56 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:39:56 +01:00
Owner
Copy Link

Originally created by @thosil on GitHub (Sep 28, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.5.4

Python version

3.10

Steps to Reproduce

  1. make sure timezone is set to UTC
  2. create a custom field of type date_time (let's say "my_dt")
  3. set a value using the nebtox UI
  4. get the value with the REST API (will be in format "YYYY-mm-ddTHH:MM:SSZ")
  5. POST a new value using the same format (with the trailing Z) or modify any other custom_field of the object → netbox does not validate the format of my_dt

Expected Behavior

The input format of datetime should be compatible with the output format.

Observed Behavior

We receive this error:

Invalid value for custom field 'start_prep': Date and time values must be in ISO 8601 format (YYYY-MM-DD HH:MM:SS).

Correct me if I'm wrong, but the values observed through the API are serialized with django rest_framework, which could explain why there's a different format between the rest api and inside the database. But when we do a post, the validation go through extras/models/customfields.py and use datetime.fromisoformat() (also for deserialisation).

Starting python 3.11 fromisoformat() is compatible with the YYYY-mm-ddTHH:MM:SSZ format, but not former version (see changed in version 3.11 in the doc). But it's not always easy to upgrade python.

I patched my version with dateutil.parser.parse() instead of datetime.fromisoformat() and it's working as expected. Should I make a PR?

Thanks

Originally created by @thosil on GitHub (Sep 28, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.5.4 ### Python version 3.10 ### Steps to Reproduce 1. make sure timezone is set to UTC 2. create a custom field of type date_time (let's say "my_dt") 3. set a value using the nebtox UI 4. get the value with the REST API (will be in format "YYYY-mm-ddTHH:MM:SSZ") 5. POST a new value using the same format (with the trailing Z) or modify any other custom_field of the object → netbox does not validate the format of my_dt ### Expected Behavior The input format of datetime should be compatible with the output format. ### Observed Behavior We receive this error: ``` Invalid value for custom field 'start_prep': Date and time values must be in ISO 8601 format (YYYY-MM-DD HH:MM:SS). ``` Correct me if I'm wrong, but the values observed through the API are serialized with django rest_framework, which could explain why there's a different format between the rest api and inside the database. But when we do a post, the validation go through extras/models/customfields.py and use `datetime.fromisoformat()` (also for deserialisation). Starting python 3.11 fromisoformat() is compatible with the YYYY-mm-ddTHH:MM:SSZ format, but not former version (see [changed in version 3.11 in the doc](https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat)). But it's not always easy to upgrade python. I patched my version with `dateutil.parser.parse()` instead of `datetime.fromisoformat()` and it's working as expected. Should I make a PR? Thanks
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 20:39:56 +01:00
adam closed this issue 2025-12-29 20:39:57 +01:00
adam commented 2025-12-29 20:39:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 26, 2023):

Unfortunately this is a limitation of the datetime.fromisoformat() in Python < 3.11. This StackOverflow question has a lot of discussion around it. (However, I'm not a fan of introducing a new dependency just to support this.)

We'll need to come up with a way to support multiple conforming date/time formats.

@jeremystretch commented on GitHub (Dec 26, 2023): Unfortunately this is a limitation of the `datetime.fromisoformat()` in Python < 3.11. [This StackOverflow question](https://stackoverflow.com/questions/127803/how-do-i-parse-an-iso-8601-formatted-date) has a lot of discussion around it. (However, I'm not a fan of introducing a new dependency just to support this.) We'll need to come up with a way to support multiple conforming date/time formats.
adam commented 2025-12-29 20:39:58 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 26, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Mar 26, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:39:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 14, 2024):

It seems the root issue is that Django REST Framework has taken it upon itself, for reasons unknown to me, to arbitrarily replace the +00:00 suffix of a timestamp with Z (for Zulu).

We can work around this for custom fields for now by replacing the Z suffix with the zero offset on incoming data.

@jeremystretch commented on GitHub (Jun 14, 2024): It seems the root issue is that Django REST Framework has taken it upon itself, for reasons unknown to me, to [arbitrarily replace](https://github.com/encode/django-rest-framework/blob/3b41f0124194430da957b119712978fa2266b642/rest_framework/fields.py#L1209-L1213) the `+00:00` suffix of a timestamp with `Z` (for Zulu). We can work around this for custom fields for now by replacing the `Z` suffix with the zero offset on incoming data.
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 severity: low 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#8691
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?