feat(utils/Date): Add time zone name to fields

[TylerAdamMartinez]

Why

This PR addresses the following problem/context:

• The frontend correctly formats UTC timestamps into America/Denver, which exposed the issue as a 6-hour shift during daylight saving time.
• Example: a CSV value entered as 11:02 was stored as 2025-06-12T11:02:00Z, which the UI correctly displayed as 5:02 AM MDT.
• Date/time fields were updated to show timezone information so the rendered time is unambiguous to users.
• Date-only fields still intentionally do not display a timezone, since those values represent calendar dates rather than meaningful instants in time.

How

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

• Updated date/time formatting to include a timezone label in UI output.

Notes

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

• The underlying bug is not in the frontend formatter; it originates in CSV import and/or backend ingestion. CSV-entered local times are being saved as if they were already UTC, rather than being converted from Denver local time to UTC before persistence.

[github-actions]

Preview Deployment

Preview URL: https://preview-tam-bdms-718-auejgdbofq-uc.a.run.app

Note: This preview uses the staging API endpoints.

[TylerAdamMartinez]

In file: OcotilloAPI/services/water_level_csv.py

Lines: 472 - 482

def _apply_observation_values(
    observation: Observation, row: _ValidatedRow, parameter_id: int
) -> None:
    observation.observation_datetime = row.measurement_dt // <-- The bug is here
    observation.parameter_id = parameter_id
    observation.value = row.depth_to_water_ft
    observation.unit = "ft"
    observation.measuring_point_height = row.resolved_mp_height
    observation.groundwater_level_reason = row.level_status
    observation.nma_data_quality = row.data_quality
    observation.notes = row.water_level_notes

The issue is here: the hydrologist enters the date and time in their local time zone (as they see on their watch), and then we store that value directly in the database as UTC without converting it from MT to UTC. So that's what the frontend gets and then converts.

[ksmuczynski]

I think the issue is only for the well inventory importer, not the water level importer. The well inventory importer does not normalize measurement_date_time to UTC before writing observation.observation_datetime or sample.sample_date.

@TylerAdamMartinez The dates from the water level importer you referenced abobe are actually converted and stored as UTC (see schemas/water_level_csv.py:87 and schemas/water_level_csv.py:178 in OcotilloAPI)

I'd suggest the following updates to the well inventory importer:

1. Extract or add a helper similar to the water level importer’s _normalize_datetime_to_utc(...).
2. Update the well inventory schema validators so:
   • date_time is normalized to UTC
   • measurement_date_time is normalized to UTC
3. Leave the importer write logic mostly unchanged; once the schema returns UTC datetimes, the existing assignments will write UTC values:
   - measurement_date_time is written to sample.sample_date and observation.observation_datetime
   - date_time is written to field_event.event_date

Relevant well inventoy importer files:

• services/well_inventory_csv.py and
• schemas/well_inventory.py)

We may also want to evaluate previously imported well inventory records for potential backfilling or updates to sample.sample_date and observation.observation_datetime, but we can open a separate ticket for this later.

[jirhiker]

sounds like a good plan. update well inventory importer and backfill already imported dates. @ksmuczynski the backfill can be tested locally and on staging, then applied to production.

[TylerAdamMartinez]

This is a backend issue. For a detailed bug fix, see OcotilloAPI PR#653.