NO TICKET: Make local tests pass

[kbighorse]

Why

This PR addresses the following problem / context:

• Tests pass against docker, but
• Tests fail against the file system

How

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

• Handled database cleanup between test runs
• Addressed timezone issues

Notes

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

• All tests pass locally now

[codecov-commenter]

Codecov Report

❌ Patch coverage is 97.08738% with 3 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
schemas/__init__.py	83.33%	3 Missing ⚠️

Files with missing lines	Coverage Δ
db/engine.py	60.00% <100.00%> (ø)
db/geochronology.py	100.00% <100.00%> (ø)
schemas/lexicon.py	100.00% <100.00%> (ø)
schemas/observation.py	98.43% <100.00%> (ø)
schemas/sample.py	98.30% <100.00%> (ø)
tests/__init__.py	100.00% <100.00%> (ø)
tests/test_asset.py	100.00% <100.00%> (ø)
tests/test_contact.py	100.00% <100.00%> (ø)
tests/test_group.py	97.08% <100.00%> (ø)
tests/test_lexicon.py	81.11% <100.00%> (ø)
... and 7 more

[Copilot]

Pull Request Overview

This PR fixes timezone-related test failures when running tests against the local filesystem instead of Docker by standardizing datetime serialization to UTC format with 'Z' suffix and ensuring proper database cleanup between test runs.

Key changes:

• Introduced UTCAwareDatetime custom type to handle consistent UTC datetime serialization across all response models
• Added database cleanup logic in test initialization to ensure clean state between runs
• Updated database connection to default to current OS user when POSTGRES_USER is not set

Reviewed Changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
tests/init.py	Added timezone configuration, dotenv loading, and database cleanup logic to ensure test isolation
schemas/init.py	Implemented UTCAwareDatetime custom type for consistent UTC datetime serialization
schemas/sample.py	Updated sample_date field to use UTCAwareDatetime
schemas/observation.py	Updated observation_datetime field to use UTCAwareDatetime
schemas/lexicon.py	Updated created_at field to use UTCAwareDatetime
db/engine.py	Modified database user resolution to default to OS username when POSTGRES_USER is empty
tests/test_thing.py	Updated datetime assertions to use explicit UTC conversion and removed redundant datetime formatting code
tests/test_sensor.py	Updated datetime assertions to use explicit UTC conversion
tests/test_sample.py	Updated datetime assertions to use explicit UTC conversion with inline timezone import
tests/test_observation.py	Updated datetime assertions to use explicit UTC conversion with inline timezone import
tests/test_location.py	Updated datetime assertions to use explicit UTC conversion
tests/test_lexicon.py	Updated datetime assertions to use explicit UTC conversion
tests/test_group.py	Updated datetime assertions to use explicit UTC conversion
tests/test_contact.py	Updated datetime assertions to use explicit UTC conversion
tests/test_asset.py	Updated datetime assertions to use explicit UTC conversion
.github/workflows/tests.yml	Added explicit POSTGRES_USER environment variable for CI workflow

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[jacob-a-brown]

I like that all datetime objects are serialized as UTC with UTCAwareDatetime. Our intention is to store all datetime records in the database as UTC. Should UTCAwareDatetime be used in all Create... schemas and return UTC objects so that both storage and serialization are guaranteed to be UTC? Or, do you think that should always be handled by a field_validator in all of the appropriate Pydantic schemas?

[kbighorse]

Definitely the former. The latter couldn't hurt as well, or at least test for it?

[kbighorse]

I created an issue for UTC enforcement