| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
| |
This needs very few changes:
- Use declarative_base from sqlalchemy.orm instead of ext [1]
- Enable the future flag on both engine and session
[1] https://docs.sqlalchemy.org/en/20/errors.html#error-b8d9
|
| | |
|
| |
|
|
| |
Since we are migrating to ruff, these are not used anymore.
|
| |
|
|
|
|
|
|
| |
The cache_ok flag was added [1] in SQLAlchemy 1.4.14 and emits a warning
if not set to either True or False. Since DateTimeUTC should be fine to
cache, indicate True here.
[1] https://docs.sqlalchemy.org/en/14/core/custom_types.html#sqlalchemy.types.TypeDecorator.cache_ok
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Quassel stores its timestamps as INTEGERs when using the SQLite backend. Since
SQLAlchemy expects strings here instead[1], we have to handle this manually.
This commit extends the existing process_result_value() function to handle a
conversion from a unix timestamp to a proper datetime object, makes sure that
the right impl is chosen for both SQLite and PostgreSQL, and adds the
process_bind_param() function which takes care of the conversion back to a unix
timestamp when binding values for SELECT statements.
[1] https://docs.sqlalchemy.org/en/14/core/type_basics.html#sqlalchemy.types.DateTime
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quassel uses UTC message timestamps in its database, but does not save
any timezone information along with them. Up until now, we were reading
those timestamps from the database naively - resulting in datetime
objects that could not be identified as UTC.
The same happened with timestamps we got from dateutil.isoparse. If the
user did not specify an offset explicitly, the timestamp would be parsed
and passed to the program "as is", effectively being interpreted as UTC
because they were compared to database timestamps.
This commit will ensure that the correct timezone is saved for every
datetime object we encounter. Timestamps from the database are marked as
UTC. If the user does not explicitly specify an offset, the timestamp is
assumed to be in local time.
Furthermore, when printing out message timestamps, make sure to convert
them to the user's local timezone first.
|
| | |
|
| |
|
