The SQLite converter that the sqlite3 library automatically registers for TIMESTAMP columns (https://github.com/python/cpython/blob/main/Lib/sqlite3/dbapi2.py#L66) ignores the time zone even if it is present and always returns a naive datetime object.

I think that the converter should return an aware object if the time zone is present in the database. As it is, round trips of TIMESTAMP values from the database to Python and back might erase the original time zone info.

Now that datetime.datetime.fromisoformat is in Python 3.7, this should be easy to implement.

Substitute "UTC offset" for "time zone" in my comment above.

I have attached a minimal Python program demonstrating data loss from this bug.

Replacing the timestamp converter with datetime.datetime.fromisoformat sounds good to me.

Unfortunately fixing this will have to be considered a backwards-incompatible change, since Python doesn't allow naive and aware datetime objects to be compared, so if sqlite3 starts returning aware datetimes, existing code might break.

Alternatively, perhaps this could be fixed in conjunction with changing sqlite3's API to allow per-database converters and adapters. Then, the old global TIMESTAMP converter could be retained for compatibility with existing code, and new code could opt-in to a per-database TIMESTAMP converter with the correct behavior.

> [...] if sqlite3 starts returning aware datetimes, existing code might break.

True.

> [...] perhaps this could be fixed in conjunction with changing sqlite3's API to allow per-database converters and adapters

Another option could be to deprecate the current behaviour and then change it to being timezone aware in Python 3.13.

> Another option could be to deprecate the current behaviour and then change it to being timezone aware in Python 3.13.

This sounds like the simplest option.

I'd be interested in working on this myself, if you think it's something that a new CPython contributor could handle.

> I'd be interested in working on this myself, if you think it's something that a new CPython contributor could handle.

Please, go ahead :)

However, I think this should be discussed on Discourse first (open a topic in the Core Development category).

Okay, I started a discussion here: https://discuss.python.org/t/fixing-sqlite-timestamp-converter-to-handle-utc-offsets/10985

See also:

- bpo-19065: sqlite3 timestamp adapter chokes on timezones
- bpo-26651 Deprecate register_adapter() and register_converter() in sqlite3


(Adding Berker to nosy list.)

New changeset 3877fc02f7a8801ba5ce0e94b6075b3fdd9778d0 by Ian Fisher in branch 'main':
bpo-45335: Add note to `sqlite3` docs about "timestamp" converter (GH-29200)
https://github.com/python/cpython/commit/3877fc02f7a8801ba5ce0e94b6075b3fdd9778d0

New changeset 8ea665c730cd86a321c558c012bef84f454efa4f by Miss Islington (bot) in branch '3.10':
bpo-45335: Add note to `sqlite3` docs about "timestamp" converter (GH-29200) (GH-29319)
https://github.com/python/cpython/commit/8ea665c730cd86a321c558c012bef84f454efa4f

New changeset e1560313d4d9bff8eba0f851ef325f7ee19f7ba9 by Miss Islington (bot) in branch '3.9':
bpo-45335: Add note to `sqlite3` docs about "timestamp" converter (GH-29200) (GH-29320)
https://github.com/python/cpython/commit/e1560313d4d9bff8eba0f851ef325f7ee19f7ba9

Based on the decision from Discourse, the current behavior has only been documented and the actual issue is "wontfix".

Thanks for pursuing this, Ian! ✨ 🍰 ✨