[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Łukasz Langa added the comment: Based on the decision from Discourse, the current behavior has only been documented and the actual issue is "wontfix". Thanks for pursuing this, Ian! ✨ 🍰 ✨ -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed versions: +Pyt

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Łukasz Langa added the comment: 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/e1560313d4d9bff8eba0f851ef325f7ee19f

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Łukasz Langa added the comment: 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/8ea665c730cd86a321c558c012bef84f454

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Change by miss-islington : -- pull_requests: +27590 pull_request: https://github.com/python/cpython/pull/29320 ___ Python tracker ___ __

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Łukasz Langa added the comment: 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 -- nos

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +27589 pull_request: https://github.com/python/cpython/pull/29319 ___ Python tracker _

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Change by Ian Fisher : -- keywords: +patch pull_requests: +27469 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29200 ___ Python tracker ___ _

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Erlend E. Aasland added the comment: 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.) -- nosy: +berker.peksag ___ Pytho

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Ian Fisher added the comment: Okay, I started a discussion here: https://discuss.python.org/t/fixing-sqlite-timestamp-converter-to-handle-utc-offsets/10985 -- ___ Python tracker

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Erlend E. Aasland added the comment: > 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). -

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Ian Fisher added the comment: > 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 contribut

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Erlend E. Aasland added the comment: > [...] 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

[issue45335] Default TIMESTAMP converter in sqlite3 ignores UTC offset

Ian Fisher added the comment: 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 t