Supporting timezone information in the DB is not trivial as we support 3 different backends with different tz support:
- sqlite: no support
- postgres: tz support
- mariadb: could support timezones, but not with the current implementation (we should use
TIMESTAMP instead of DateTime column according to sqlalchemy's documentation).
This complicates the handling of user requests for accounting information where we filter against row's datetime information (revoked_at or ended_at` for example).
I'd suggest removing timezone=True from the model's definitions and handling all data as utc and mutating eventual tz-aware requests from users (eg when filtering accounting data) to naive utc datetime data.
Supporting timezone information in the DB is not trivial as we support 3 different backends with different tz support:
TIMESTAMPinstead ofDateTimecolumn according to sqlalchemy's documentation).This complicates the handling of user requests for accounting information where we filter against row's datetime information (
revoked_at orended_at` for example).I'd suggest removing
timezone=Truefrom the model's definitions and handling all data as utc and mutating eventual tz-aware requests from users (eg when filtering accounting data) to naive utc datetime data.