Skip to content

NO TICKET: enable user to submit tz-naive datetime objects #311

Merged
chasetmartin merged 5 commits into
well-inventory-csvfrom
well-inventory-csv-dt-updates
Dec 18, 2025
Merged

NO TICKET: enable user to submit tz-naive datetime objects #311
chasetmartin merged 5 commits into
well-inventory-csvfrom
well-inventory-csv-dt-updates

Conversation

@jacob-a-brown

@jacob-a-brown jacob-a-brown commented Dec 17, 2025

Copy link
Copy Markdown
Contributor

Why

This PR addresses the following problem / context:

  • All datetime fields are necessarily in Mountain Time since all locations must be in New Mexico. To facilitate the upload of data and ensure the user doesn't need to keep track of MST/MDT they now submit timezone-naive objects.
  • These changes address the following updates to well-inventory-csv.feature that were made in PR NO TICKET: Update well inventory csv feature field names #307:
  • And the required "date_time" values are valid ISO 8601 timezone-naive datetime strings (e.g. "2025-02-15T10:30:00")
  • And the optional "water_level_date_time" values are valid ISO 8601 timezone-naive datetime strings (e.g. "2025-02-15T10:30:00") when provided
  • Then all datetime objects are assigned the correct Mountain Time timezone offset based on the date value.

How

Implementation summary - the following was changed / added / removed:

  • Add the timezone to the provided datetime fields and handle MST/MDT correctly with Python's ZoneInfo library
  • Update the testing data to remove timezone offsets

Notes

Any special considerations, workarounds, or follow-up work to note?

  • Use bullet points here

…V tests

This is no longer a requiremented of the incoming data and it will be
handled by the API.
…DT data

This ensures that the timezone offset being added to the datetime fields
are being handled correctly
the users shouldn't need to care about the timezone or offsets
being submitted. since we know that all incoming times are in Mountain
Time the code now converts naive datetimes to timezone-aware datetimes
assuming Mountain Time before further processing. The code handles
MST and MDT as appropriate.

@chasetmartin chasetmartin left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. It seems like if a future version of this well-inventory code is used to handle records sent individually from OcotilloUI (not from a csv), we'll have to circle back on the date/time format required.

@jacob-a-brown

Copy link
Copy Markdown
Contributor Author

That's definitely a good thing to keep in mind. Two things come to mind:

  1. If users are only submitting water levels in New Mexico we can continue to use timezone-naive dt strings and continue as-is.
  2. If users are submitting water levels from anywhere in the world, we can use the well's current location to determine the timezone and then add the timezone offset to the record appropriately

@jirhiker

Copy link
Copy Markdown
Member

I think for this case it's ok to assume that all datetimes will be in mountain time. However in general we should not assume all locations will be in New Mexico. Bureau researchers collect and analyze samples from all over Earth and even beyond.

@chasetmartin chasetmartin merged commit 3867554 into well-inventory-csv Dec 18, 2025
4 checks passed
@TylerAdamMartinez TylerAdamMartinez deleted the well-inventory-csv-dt-updates branch February 26, 2026 18:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants