Task #120
openenforce timezone handling rules
0%
Description
For each entity that has timestamps we need to
at the API route level: get timestamps from the user, convert to UTC
assume incoming timestamps are in user's local timezone unless a flag for UTC is set
if creating an entity:
give it friendly in-zone display fields
and function-focused UTC fields.
accept and display in local
work in UTC
Updated by Sam Pearson 3 months ago
The right pattern here is to convert all timestamps from the DB's UTC datetime object into a localized timestamp through the db model's as_dict function.
so convert this:
"start_time": "2026-04-02T09:00:00+00:00"
into this
"start_time": "09:00"
or this, where appropriate:
"start_time": "2026-04-02T09:00"
Doing this will break all timestamp-related tests and should be done in conjunction with creation of a bunch of new timezone/timestamp-focused tests for all entities.
Updated by Sam Pearson 23 days ago
- Priority changed from Normal to High
- Engineering Effort set to large
- App Component set to Database
pretty big task.
Need to
- identify all entities that use timestamps
- ensure all these entities convert local time to utc on the way in (maybe in the service layer) and convert utc to user's local on the way out (service layer or db's to_dict() method )
- clean up any handling that occurs outside the canonical locations
Updated by Sam Pearson 22 days ago
I've decided against implementing timezone conversion logic in the as_dict functions; the logic is complex enough that it deserves its own home.
I'm going to implement a layer between the service and API layers, there will be one module per entity (in the database folder for that entity).
Updated by Sam Pearson 21 days ago
I ended up just storing timezones for calendars,routines, and sessions.
Additionally there's a presentation layer in the database that can be used to translate timestamps between timezones, but hopefully it won't get much use as we're storing timezone info in the calendar/routine/session.
we're no longer "JUST DO EVERYTHING IN UTC" but that would have been a mess for recurring events that are less than 6 hours away from the date boundary.
Anyway, timestamps come through the API and frontend cleanly now.
commitments, checkins, and timeframes will still be encoded in UTC.
Still probably need to do some testing around these