# Extract() isn't safe to use in db\_default on SQLite if TIME\_ZONE changes at some point

**URL:** <https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-db-default-on-sqlite-if-time-zone-changes-at-some-point/44781>\
**Category:** ORM\
**Created:** [March 30, 2026, 1:45am UTC](https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-db-default-on-sqlite-if-time-zone-changes-at-some-point/44781 "2026-03-30T01:45:46Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![charettes](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/charettes/32/27_2.png) [@charettes](https://forum.djangoproject.com/u/charettes)\
**Post date:** [March 30, 2026, 2:41pm UTC](https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-db-default-on-sqlite-if-time-zone-changes-at-some-point/44781/6 "2026-03-30T14:41:08Z")

</div>

If we also want to cover the case of changing `TIME_ZONE` during the lifetime of the project we could adjust `Extract.deconstruct` to prevent not providing a `tzinfo` (through a deprecation period) and then adjust it to return `tzinfo=get_current_timezone()` when not provided.

This would ensure that the timezone is always captured in the migrations file and if it ever change in the future the adequate operations would be generated.

I see it as a distinct problem than the `db_default` one though.

---

_[View the full topic](https://forum.djangoproject.com/t/extract-isnt-safe-to-use-in-db-default-on-sqlite-if-time-zone-changes-at-some-point/44781)._