Can't set timezone-naive datetimes
See original GitHub issueDescribe the bug Can’t set timezone-naive datetimes
To Reproduce
- Model with two
DatetimeField
s and typesqlalchemy.DateTime(timezone=False)
- Save timezone-naive datetime to first field (All ok)
- Save timezone-naive datetime to second field (Error, can’t compare aware and naive dts)
values
from backends/base/executor.py:execute_update
:
- from first execute:
[datetime.datetime(2021, 2, 2, 0, 0), None]
- from second:
[datetime.datetime(2021, 2, 2, 0, 0, tzinfo=<UTC>), datetime.datetime(2021, 3, 17, 14, 38, 11)]
So, as we can see, on second execute, first field value have UTC timezone
Expected behavior Timezone-naive fields
Additional context PostgreSQL : latest Tortoise-orm : latest Alembic with SQLAlchemy (for migrations) : latest
Issue Analytics
- State:
- Created 3 years ago
- Comments:10
Top Results From Across the Web
How to make a timezone aware datetime object
In general, to make a naive datetime timezone-aware, use the localize method: import datetime import pytz unaware = datetime.datetime(2011, ...
Read more >Working with Datetime Objects and Timezones in Python
A naive datetime object contains no timezone information. The easiest way to tell if a datetime object is naive is by checking tzinfo....
Read more >How to make a timezone aware datetime object in Python
We can easily check if a datetime object is timezone-aware or not. For this, we will store the current date and time in...
Read more >Why naïve times are local times in Python
The reason for this is simple: it's possible to change your system local time zone during the run of a Python program, and...
Read more >Working With TimeZones in Python
Create Timezone Aware Datetime Object · Install pytz module if not installed using the pip install pytz command. · Use the pytz.timezone(' ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Having the same issue,
tl;dr is that the column schema in postgres is
timezone without time zone
but tortoise’s auto create and auto update timestamp functions are always datetime awareThe docs in tortoise orm state
and tortoise achieves this with setting its “now” on auto create and auto update timestamps to be
As you can see, both of these create timezone-aware datetimes. Because these are timezone aware (despite being UTC), they can not be compared to the database timezone-naive (
timestamp without time zone
in psql) at the adapter (asyncpg
) level.My practice (and generally as well, to my knowledge) is to store UTC timestamps in postgres but keep them timezone naive. Tortoise’s implementation has changed to keep all postgres columns
TIMESTAMPTZ
ortimestamp with time zone
which clashes with the underlying column.One option here is to change all your created and updated columns in your database to be timezone aware at UTC.
Personally, I’m going to run a fork of this going forward with the change that all my timezone columns will have the
SQL_TYPE
oftimestamp without time zone
and will strictly usedatetime.utcnow()
… like the description says in the first place…What I hope tortoise-orm adopts, however, is for
USE_TZ
to actually do what its name implies in thattimezone
timestamp without time zone
for postgres)tortoise.timestamp.now()
function return `datetime.utcnow(), a timezone naive datetimeFaced the same issue. I tried with use_tz=True and use_tz=False options, both are failed.