Skip to content

Fix timezone loss and time shifts in encrypted datetimes - #8

Merged
script3r merged 1 commit into
codex/fix-encrypted-lookupsfrom
codex/fix-encrypted-datetimes
Sep 5, 2026
Merged

Fix timezone loss and time shifts in encrypted datetimes#8
script3r merged 1 commit into
codex/fix-encrypted-lookupsfrom
codex/fix-encrypted-datetimes

Conversation

@script3r

@script3r script3r commented Sep 5, 2026

Copy link
Copy Markdown
Owner

With USE_TZ=True, encrypted datetimes stored by SQLite were decrypted as naive values because binary columns skip Django's datetime result converters. Re-saving a value under a non-UTC default timezone could shift the instant and break deterministic equality lookups.

Restore the connection timezone after decrypting naive datetime representations. Already-aware values and USE_TZ=False retain their behavior. Serialization is unchanged, so existing ciphertext and deterministic equality remain compatible without a data migration.

Validation: 6 new cases failed before the fix. All 102 library tests and 6 example tests pass on Python 3.14 / Django 6.0 and Python 3.10 / Django 5.2 / Tink 1.13.0. Tests cover UTC and non-UTC database timezones, raw ciphertext, existing offset and naive representations, values_list(), re-saves, and deterministic equality. Ruff lint/format and Pyright pass.

Stack position: 2 of 6; depends on #7. Land #7 first, then retarget this PR to main if GitHub has not done so automatically. Database integration was tested with SQLite.

Landing order: #7#8#9#10#11#12.

Full review and landing notes. Use merge commits to preserve stack ancestry; squash/rebase merges require rebasing the remaining stack before landing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant