Parse non-RFC3339 `added_at` values in list rows #21

New issue

Closed

opened 2026-04-27 23:30:28 +02:00 by umpire274 · 0 comments

umpire274 commented

2026-04-27 23:30:28 +02:00

(Migrated from github.com)

** Parse non-RFC3339 added_at values in list rows**

row_to_book now calls Book::from_row, which loads added_at as Option<DateTime<Utc>>. In rusqlite, that conversion expects RFC3339 or unix timestamps, but this codebase writes added_at via SQLite CURRENT_TIMESTAMP (YYYY-MM-DD HH:MM:SS), so listing can now fail with a row conversion error instead of rendering results. The previous mapper explicitly parsed SQLite timestamp formats and degraded to None, so this introduces a regression for databases containing default timestamp strings.

Useful? React with 👍 / 👎.

Originally posted by @chatgpt-codex-connector[bot] in https://github.com/umpire274/librius/pull/20#discussion_r3150292425

** Parse non-RFC3339 `added_at` values in list rows** `row_to_book` now calls `Book::from_row`, which loads `added_at` as `Option<DateTime<Utc>>`. In rusqlite, that conversion expects RFC3339 or unix timestamps, but this codebase writes `added_at` via SQLite `CURRENT_TIMESTAMP` (`YYYY-MM-DD HH:MM:SS`), so listing can now fail with a row conversion error instead of rendering results. The previous mapper explicitly parsed SQLite timestamp formats and degraded to `None`, so this introduces a regression for databases containing default timestamp strings. Useful? React with 👍 / 👎. _Originally posted by @chatgpt-codex-connector[bot] in https://github.com/umpire274/librius/pull/20#discussion_r3150292425_