Postgresql DB Engine Error: '>=' not supported between instances of 'datetime.timedelta' and 'int' #15768

anggxyz · 2021-07-18T16:53:04Z

There seems to be a problem in retrieving and using any column that is of the format: TIMESTAMP WITH TIME ZONE or just TIMESTAMP

A relational table with a column of type TIMESTAMP WITH TIME ZONE would error when run a SELECT * ... or SELECT <column_with_timestamp_type> FROM...

The SQL editor errors even with SELECT now()

The error is:

DB engine Error

postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'

This may be triggered by:
Issue 1002 - The database returned an unexpected error.

Expected results

Would expect the column to return properly and be usable in exploration

Actual results & Screenshots

How to reproduce the bug

Go to SQL Lab
run the query: SELECT now()

Environment

my requirements.txt:

aiohttp==3.7.4.post0
alembic==1.6.5
amqp==2.6.1
apache-superset==1.2.0
apispec==3.3.2
async-timeout==3.0.1
attrs==21.2.0
Babel==2.9.1
backoff==1.11.1
billiard==3.6.4.0
bleach==3.3.1
Brotli==1.0.9
cachelib==0.1.1
celery==4.4.7
cffi==1.14.6
chardet==4.0.0
click==7.1.2
colorama==0.4.4
contextlib2==21.6.0
convertdate==2.3.2
cron-descriptor==1.2.24
croniter==1.0.15
cryptography==3.4.7
decorator==5.0.9
defusedxml==0.7.1
dnspython==2.1.0
email-validator==1.1.3
Flask==1.1.4
Flask-AppBuilder==3.3.1
Flask-Babel==1.0.0
Flask-Caching==1.10.1
Flask-Compress==1.10.1
Flask-JWT-Extended==3.25.1
Flask-Login==0.4.1
Flask-Migrate==3.0.1
Flask-OpenID==1.2.5
Flask-SQLAlchemy==2.5.1
flask-talisman==0.8.1
Flask-WTF==0.14.3
geographiclib==1.52
geopy==2.2.0
graphlib-backport==1.0.3
gunicorn==20.0.4
holidays==0.10.3
humanize==3.10.0
idna==3.2
isodate==0.6.0
itsdangerous==1.1.0
Jinja2==2.11.3
jsonschema==3.2.0
kombu==4.6.11
korean-lunar-calendar==0.2.1
Mako==1.1.4
Markdown==3.3.4
MarkupSafe==2.0.1
marshmallow==3.12.2
marshmallow-enum==1.5.1
marshmallow-sqlalchemy==0.23.1
msgpack==1.0.2
multidict==5.1.0
numpy==1.21.0
packaging==21.0
pandas==1.2.5
parsedatetime==2.6
pathlib2==2.3.6
pgsanity==0.2.9
polyline==1.4.0
prison==0.1.3
psycopg2==2.9.1
py==1.10.0
pyarrow==3.0.0
pycparser==2.20
PyJWT==1.7.1
PyMeeus==0.5.11
pyparsing==2.4.7
pyrsistent==0.18.0
python-dateutil==2.8.2
python-dotenv==0.18.0
python-editor==1.0.4
python-geohash==0.8.5
python3-openid==3.2.0
pytz==2021.1
PyYAML==5.4.1
redis==3.5.3
retry==0.9.2
selenium==3.141.0
simplejson==3.17.3
six==1.16.0
slackclient==2.5.0
SQLAlchemy==1.3.24
SQLAlchemy-Utils==0.36.8
sqlparse==0.3.0
typing-extensions==3.10.0.0
urllib3==1.26.6
vine==1.3.0
webencodings==0.5.1
Werkzeug==1.0.1
WTForms==2.3.3
WTForms-JSON==0.3.3
yarl==1.6.3

Checklist

Make sure to follow these steps before submitting your issue - thank you!

I have checked the superset logs for python stacktraces and included it here as text if there are any.
I have reproduced the issue with at least the latest released version of superset.
I have checked the issue tracker for the same issue and I haven't found one similar.

The text was updated successfully, but these errors were encountered:

zhaoyongjie · 2021-07-19T01:53:48Z

Hi @nglglhtr.
I can't reproduce this issue on the latest master branch.

srinify · 2021-07-19T14:29:53Z

Hi @nglglhtr I'm not able to reproduce this issue:

Can you add some more details reproduction instructions / share a video ideally using the default examples datasets?

wildsonc · 2021-07-19T19:01:26Z

I have two instances, but only one have this issue

srinify · 2021-07-19T19:15:32Z

This will be hard to debug / fix if we can't reproduce :( Can you share more context?

Are you doing any >= comparison in the superset semantic layer anywhere? (e.g. metrics, calculated columns, etc).

wildsonc · 2021-07-19T20:12:44Z

I have 2 superset's connected in same database.

Node 1:

Node 2:

Query error:
Query 56: <class 'TypeError'> 2021-07-19 17:06:23,715:ERROR:superset.sql_lab:Query 56: <class 'TypeError'> postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int' 2021-07-19 17:06:23,840:WARNING:superset.views.base:postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'

This error appears when there is a column of type date/timestamp, when I remove this column it works

zhaoyongjie · 2021-07-20T02:31:07Z

Hi @wildsonc Do you mind share your config file?

wildsonc · 2021-07-20T14:08:47Z

superset_conifg.txt

The error occurs in this connected database

URI SQLALCHEMY: postgresql+psycopg2://explorernet:XXXXXXXXXX@10.9.35.41:5432/web_caixas
EXTRA: {
"metadata_params": {},
"engine_params": {},
"metadata_cache_timeout": {},
"schemas_allowed_for_csv_upload": []
}

No other options are checked in connection settings.

vijayadeeptim · 2021-07-20T14:42:51Z

Facing the same issue with the instance on superset , has there been any patches released recently ? I'm not able to upload the error but its pretty much the same as posted in some of the above posts

anggxyz · 2021-07-20T16:55:16Z

@srinify

Are you doing any >= comparison in the superset semantic layer anywhere? (e.g. metrics, calculated columns, etc).

Not really, I'm simply trying to query a database that consists of a column of type timestamp

anggxyz · 2021-07-20T16:56:20Z

Some more context:

the docker image doesn't have this error, which is what I used for local debugging and trying
the pip install superset is what i used for my heroku deployment - which is what gives this error

soitgoes511 · 2021-07-25T08:17:27Z

Same issue here. Docker instance had no issues with connecting to local postgres db but my local install of apache-superset installed via pip in venv yielded the following error despite successful connection w/ postgresql instance:

DB engine Error
postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'

See more

And here is the query (very simple w/o any relational operators):

SELECT *
FROM pulse_ox_moving_average;

Here are the only packages installed in the venv, apart from apache-superset, I installed psycopg2 and that is all.

requirements.txt
`
I do have one timestamped column, but this was a non-issue w/ the docker-compose install.

soitgoes511 · 2021-07-25T10:26:09Z

After further experimentation, the issue seems to be timezones. If I removed the timezone offset with to_char(), my query works.

Update:

I was able to work around the issue with the following query:

SELECT (time at time zone 'CEST')::timestamp without time zone AS "time",
       ma_spo2,
       ma_bpm,
       ma_perf
FROM pulse_ox_moving_average

This hack would allow me to create time-series charts where as using to_char would not. Setting a timezone and then localizing by removing the timezone is not ideal for the long term.

Ruframapi · 2021-07-26T21:47:33Z

I downgraded the version of psycopg2 and psycopg2-binary to 2.8.6 and the problem was fixed. I assume there is a problem with version 2.9.X.

soitgoes511 · 2021-07-26T21:52:59Z

That did the trick. Very much appreciated. ✔️

amrishparmar · 2021-08-06T15:19:57Z

Dowgrading from 2.9.1 -> 2.8.6 was also the solution in my case.

Could quite possibly be related to this change listed in the 2.9 release notes?

Use datetime.timezone objects by default in datetime objects instead of FixedOffsetTimezone

mail2lawi · 2021-08-12T06:49:37Z

Following on your suggestion, I fixed it by editing the date column expression in the dataset editor window:

After further experimentation, the issue seems to be timezones. If I removed the timezone offset with to_char(), my query works.

Update:

I was able to work around the issue with the following query:
SELECT (time at time zone 'CEST')::timestamp without time zone AS "time",
       ma_spo2,
       ma_bpm,
       ma_perf
FROM pulse_ox_moving_average
This hack would allow me to create time-series charts where as using to_char would not. Setting a timezone and then localizing by removing the timezone is not ideal for the long term.

jonathanStrange0 · 2021-08-20T09:54:20Z

I can replicate this issue using a fresh install of the latest docker image per the instructions here.

Screenshot below.

According to a pip freeze in the app container (superset_app), this version is using psycopg2 v. 2.9.1.

Manually replacing version 2.9.1 with 2.8.6 as suggested above resolves the issue.

@mail2lawi's solution above (time at time zone 'CEST')... also was an effective fix, leading me to support the hypothesis that this issue is specifically related to columns which contain timestamptz values.

Thank you for your help all!

dsidlo · 2021-08-23T18:19:39Z

I am getting this error on the current master branch...

commit bc4b6f0 (HEAD -> master, origin/master, origin/HEAD)
Author: John Bodley 4567245+john-bodley@users.noreply.github.com
Date: Mon Aug 23 10:20:52 2021 -0700

I am connecting to postgresql 11.10.

Here is what I see in my logs...

superset_app | 2021-08-23 18:17:13,022:INFO:superset.views.core:Triggering query_id: 34
superset_app | Query 34: Executing 1 statement(s)
superset_app | 2021-08-23 18:17:13,052:INFO:superset.sql_lab:Query 34: Executing 1 statement(s)
superset_app | Query 34: Set query to 'running'
superset_app | 2021-08-23 18:17:13,052:INFO:superset.sql_lab:Query 34: Set query to 'running'
superset_app | Query 34: Running statement 1 out of 1
superset_app | 2021-08-23 18:17:13,177:INFO:superset.sql_lab:Query 34: Running statement 1 out of 1
superset_app | Query 34: <class 'TypeError'>
superset_app | Traceback (most recent call last):
superset_app | File "/app/superset/sql_lab.py", line 276, in execute_sql_statement
superset_app | data = db_engine_spec.fetch_data(cursor, increased_limit)
superset_app | File "/app/superset/db_engine_specs/postgres.py", line 174, in fetch_data
superset_app | return super().fetch_data(cursor, limit)
superset_app | File "/app/superset/db_engine_specs/base.py", line 510, in fetch_data
superset_app | raise cls.get_dbapi_mapped_exception(ex)
superset_app | File "/app/superset/db_engine_specs/base.py", line 508, in fetch_data
superset_app | return cursor.fetchall()
superset_app | File "/usr/local/lib/python3.7/site-packages/pytz/init.py", line 403, in init
superset_app | if abs(minutes) >= 1440:
superset_app | TypeError: '>=' not supported between instances of 'datetime.timedelta' and 'int'
superset_app | 2021-08-23 18:17:13,201:ERROR:superset.sql_lab:Query 34: <class 'TypeError'>
superset_app | Traceback (most recent call last):
superset_app | File "/app/superset/sql_lab.py", line 276, in execute_sql_statement
superset_app | data = db_engine_spec.fetch_data(cursor, increased_limit)
superset_app | File "/app/superset/db_engine_specs/postgres.py", line 174, in fetch_data
superset_app | return super().fetch_data(cursor, limit)
superset_app | File "/app/superset/db_engine_specs/base.py", line 510, in fetch_data
superset_app | raise cls.get_dbapi_mapped_exception(ex)
superset_app | File "/app/superset/db_engine_specs/base.py", line 508, in fetch_data
superset_app | return cursor.fetchall()
superset_app | File "/usr/local/lib/python3.7/site-packages/pytz/init.py", line 403, in init
superset_app | if abs(minutes) >= 1440:
superset_app | TypeError: '>=' not supported between instances of 'datetime.timedelta' and 'int'
superset_app | [SupersetError(message="postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'", error_type=<SupersetErrorType.GENERIC_DB_ENGINE_ERROR: 'GENERIC_DB_ENGINE_ERROR'>, level=<ErrorLevel.ERROR: 'error'>, extra={'engine_name': 'PostgreSQL', 'issue_codes': [{'code': 1002, 'message': 'Issue 1002 - The database returned an unexpected error.'}]})]
superset_app | Traceback (most recent call last):
superset_app | File "/app/superset/views/base.py", line 204, in wraps
superset_app | return f(self, *args, **kwargs)
superset_app | File "/app/superset/utils/log.py", line 242, in wrapper
superset_app | value = f(*args, **kwargs)
superset_app | File "/app/superset/views/core.py", line 2578, in sql_json
superset_app | return self.sql_json_exec(request.json, log_params)
superset_app | File "/app/superset/views/core.py", line 2767, in sql_json_exec
superset_app | session, rendered_query, query, expand_data, log_params
superset_app | File "/app/superset/views/core.py", line 2563, in _sql_json_sync
superset_app | [SupersetError(**params) for params in data["errors"]]
superset_app | superset.exceptions.SupersetErrorsException: [SupersetError(message="postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'", error_type=<SupersetErrorType.GENERIC_DB_ENGINE_ERROR: 'GENERIC_DB_ENGINE_ERROR'>, level=<ErrorLevel.ERROR: 'error'>, extra={'engine_name': 'PostgreSQL', 'issue_codes': [{'code': 1002, 'message': 'Issue 1002 - The database returned an unexpected error.'}]})]
superset_app | 2021-08-23 18:17:13,219:WARNING:superset.views.base:[SupersetError(message="postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'", error_type=<SupersetErrorType.GENERIC_DB_ENGINE_ERROR: 'GENERIC_DB_ENGINE_ERROR'>, level=<ErrorLevel.ERROR: 'error'>, extra={'engine_name': 'PostgreSQL', 'issue_codes': [{'code': 1002, 'message': 'Issue 1002 - The database returned an unexpected error.'}]})]
superset_app | Traceback (most recent call last):
superset_app | File "/app/superset/views/base.py", line 204, in wraps
superset_app | return f(self, *args, **kwargs)
superset_app | File "/app/superset/utils/log.py", line 242, in wrapper
superset_app | value = f(*args, **kwargs)
superset_app | File "/app/superset/views/core.py", line 2578, in sql_json
superset_app | return self.sql_json_exec(request.json, log_params)
superset_app | File "/app/superset/views/core.py", line 2767, in sql_json_exec
superset_app | session, rendered_query, query, expand_data, log_params
superset_app | File "/app/superset/views/core.py", line 2563, in _sql_json_sync
superset_app | [SupersetError(**params) for params in data["errors"]]
superset_app | superset.exceptions.SupersetErrorsException: [SupersetError(message="postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'", error_type=<SupersetErrorType.GENERIC_DB_ENGINE_ERROR: 'GENERIC_DB_ENGINE_ERROR'>, level=<ErrorLevel.ERROR: 'error'>, extra={'engine_name': 'PostgreSQL', 'issue_codes': [{'code': 1002, 'message': 'Issue 1002 - The database returned an unexpected error.'}]})]

The error is...

PostgreSQL Error
postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'
This may be triggered by:
Issue 1002 - The database returned an unexpected error.

This is the DDL for the main timestamp field...

created_at TIMESTAMP WITH TIME ZONE

dsidlo · 2021-08-23T18:30:10Z

The error seems to be related the following code...

superset_app | File "/usr/local/lib/python3.7/site-packages/pytz/init.py", line 403, in init
superset_app | if abs(minutes) >= 1440:
superset_app | TypeError: '>=' not supported between instances of 'datetime.timedelta' and 'int'
superset_app | [SupersetError(message="postgresql error: '>=' not supported between instances of 'datetime.timedelta' and 'int'", error_type=<SupersetErrorType.GENERIC_DB_ENGINE_ERROR: 'GENERIC_DB_ENGINE_ERROR'>, level=<ErrorLevel.ERROR: 'error'>, extra={'engine_name': 'PostgreSQL', 'issue_codes': [{'code': 1002, 'message': 'Issue 1002 - The database returned an unexpected error.'}]})]

The minutes variable is a datetime.timedelta object, which is not compatible with the '>=' operator against and int, in python.
I'm using python 3.7.9.

santicomp2014 · 2021-08-24T01:48:22Z

I can replicate this issue using a fresh install of the latest docker image per the instructions here.

Screenshot below.

According to a pip freeze in the app container (superset_app), this version is using psycopg2 v. 2.9.1.

Manually replacing version 2.9.1 with 2.8.6 as suggested above resolves the issue.

@mail2lawi's solution above (time at time zone 'CEST')... also was an effective fix, leading me to support the hypothesis that this issue is specifically related to columns which contain timestamptz values.

Thank you for your help all!

Hi @jonathanStrange0 , I'm new to superset.
How do you change the version, I cloned master and found ["psycopg2-binary==2.8.5" as a dependency.
This version appears to be older than 2.8.6 and I get the same error.

What are the steps to change the version with docker-compose.
Thank you very much.

soitgoes511 · 2021-08-25T19:34:57Z

@santicomp2014,

You should just be able to:

Clone the repo: $ git clone https://github.com/apache/superset.git
$ cd superset/requirements/
Change both docker.txt and development.txt to psycopg2-binary==2.8.6
Run: $ docker-compose -f docker-compose-non-dev.yml up

dsidlo · 2021-08-26T20:34:22Z

As a work-around I convert the date to a string.
So instead of...

select rfq._created_dt, ...

use...

select to_char(rfq._created_dt, 'YYY-MM-DD') as _created_dt, ...

The actual error does not seem to come from the Postgres server as indicated by the error message.
I did some debugging, and it turns out that in the condition...
if abs(minutes) >= 1440:
... minutes is a datetime.timedelta object which can't be evaluated against and int using the '>=' operator.
But exception shows up as if it were coming from postgres.

dsidlo · 2021-08-28T04:47:12Z

As a work-around I convert the date to a string.
So instead of...

select rfq._created_dt, ...

use...

select to_char(rfq._created_dt, 'YYY-MM-DD') as _created_dt, ...

The actual error does not seem to come from the Postgres server as indicated by the error message.
I did some debugging, and it turns out that in the condition...
if abs(minutes) >= 1440:
... minutes is a datetime.timedelta object which can't be evaluated against and int using the '>=' operator.
But exception shows up as if it were coming from postgres.

String solution does not work well, it will cause other problems with some visualizations. The real issue is that (with Postgres) dates can be missing the timezone in some way, and forcing a timezone into the output field fixes the date issue properly without making it a string. Making the main temporal date field into a string, will cause other problems.

So, for date fields, don't use...
select date_fld, ...
Add the timezone to the field...
select date_fld::timestamptz at time zone 'EST',

frafra · 2021-09-13T12:02:51Z

Same problem happens when using "Big Number with Trendline" and doing a COUNT(*) over a timestamp column. Using Docker image apache/superset:4dc859f89e5668ed3f94cd1ef0532a301a3ab85a

…b engine with psycopg2==2.9.1

lsyarn · 2021-09-26T05:00:19Z

Work fine after modify postgres db engine, and timezone offset problem in explore solved.
Steps with docker-compose instance(version=1.3.1).

docker exec -it superset_app /bin/bash
apt-get update
apt-get install vim
vim /app/superset/db_engine_specs/postgres.py 
# delete line 171 (cursor.tzinfo_factory = FixedOffsetTimezone)
exit
# back to host machine
docker-compose -f docker-compose-non-dev.yml restart

psycopg 2.9 release note
psycopg2 updated to use datetime.timezone as tz property of datetime object, we do not need pytz._FixedOffset any more.

update 2022-01-11

Should have been resolved by this #17713

anujpareeksynoriq · 2021-10-08T17:28:30Z

Dowgrading from 2.9.1 -> 2.8.6 was also the solution in my case.

Could quite possibly be related to this change listed in the 2.9 release notes?

Use datetime.timezone objects by default in datetime objects instead of FixedOffsetTimezone

I downgraded the version of psycopg2 and psycopg2-binary to 2.8.6 and the problem was fixed. I assume there is a problem with version 2.9.X.

How to do it? What all files to change and what command to fire after changing version in files.

cclements128 · 2021-10-21T23:17:29Z

Is this an issue that will be fixed soon?
In its current state, Superset charts and datasets don't work with any Postgresql columns of type "timestamp with time zone".

jsanko9 · 2021-11-13T14:41:55Z

Maybe label should be changed ? Feel like this is being forgotten because of that.
Additionally @Isyarn may have even found a fix already.
Unfortunately, I don't feel competent enough to create PR.

* bump py version for integration test * bump py * bump py * remove files * lock pylint * add not-callable

raivtash · 2021-11-23T00:37:36Z

Work fine after modify postgres db engine, and timezone offset problem in explore solved. Steps with docker-compose instance(version=1.3.1).
docker exec -it superset_app /bin/bash
apt-get update
apt-get install vim
vim /app/superset/db_engine_specs/postgres.py 
# delete line 171 (cursor.tzinfo_factory = FixedOffsetTimezone)
exit
# back to host machine
docker-compose -f docker-compose-non-dev.yml restart
psycopg 2.9 release note psycopg2 updated to use datetime.timezone as tz property of datetime object, we do not need pytz._FixedOffset any more.

This fix did not work for me. But reverting psycopg2-binary to 2.8.5 solved my problem.

pvergain · 2021-12-06T16:22:50Z

Work fine after modify postgres db engine, and timezone offset problem in explore solved. Steps with docker-compose instance(version=1.3.1).
docker exec -it superset_app /bin/bash
apt-get update
apt-get install vim
vim /app/superset/db_engine_specs/postgres.py 
# delete line 171 (cursor.tzinfo_factory = FixedOffsetTimezone)
exit
# back to host machine
docker-compose -f docker-compose-non-dev.yml restart
psycopg 2.9 release note psycopg2 updated to use datetime.timezone as tz property of datetime object, we do not need pytz._FixedOffset any more.

This solution works for me but this solution seems better: #15768 (comment)

pvergain · 2021-12-07T12:37:20Z

I can replicate this issue using a fresh install of the latest docker image per the instructions here.
Screenshot below.

According to a pip freeze in the app container (superset_app), this version is using psycopg2 v. 2.9.1.
Manually replacing version 2.9.1 with 2.8.6 as suggested above resolves the issue.
@mail2lawi's solution above (time at time zone 'CEST')... also was an effective fix, leading me to support the hypothesis that this issue is specifically related to columns which contain timestamptz values.
Thank you for your help all!

Hi @jonathanStrange0 , I'm new to superset. How do you change the version, I cloned master and found ["psycopg2-binary==2.8.5" as a dependency. This version appears to be older than 2.8.6 and I get the same error.

What are the steps to change the version with docker-compose. Thank you very much.

Hi !

For docker-compose-non-dev, here is my "hack":

    docker-compose -f docker-compose-non-dev.yml up
    docker-compose -f docker-compose-non-dev.yml exec superset pip uninstall -y psycopg2-binary
    docker-compose -f docker-compose-non-dev.yml exec superset pip install psycopg2-binary==2.8.6
    docker-compose -f docker-compose-non-dev.yml restart superset

Before the hack

After the hack

pvergain · 2021-12-07T12:40:42Z

@santicomp2014,

You should just be able to:

* Clone the repo:  $ git clone https://github.com/apache/superset.git

* $ cd superset/requirements/

* Change both **docker.txt** and **development.txt** to _psycopg2-binary==2.8.6_

* Run: $ docker-compose -f docker-compose-non-dev.yml up

For me, this didn't work. I found this "hack" : #15768 (comment)

    docker-compose -f docker-compose-non-dev.yml up
    docker-compose -f docker-compose-non-dev.yml exec superset pip uninstall -y psycopg2-binary
    docker-compose -f docker-compose-non-dev.yml exec superset pip install psycopg2-binary==2.8.6
    docker-compose -f docker-compose-non-dev.yml restart superset

poxeron · 2021-12-09T00:21:54Z

This library (psycopg2-binary) was not installed at all.

pip uninstall -y psycopg2-binary
pip install psycopg2-binary==2.8.6

ronaldvanrij · 2021-12-10T16:19:40Z

Glad to see there are workarounds possible, however I'd prefer to use the official Docker image posted to Dockerhub. Any idea when this fix can be made available there?

basaravikiran · 2022-01-28T16:53:10Z

I also had the same issue and downgrading psycopg2 from 2.9.1 to 2.8.6 did fix it.

villebro · 2022-01-28T17:09:57Z

This has been fixed on master branch here: #17713 , closing

Issue with psycopg2 version workaround: apache/superset#15768 Fixed in (unreleased) Superset: apache/superset#17713

* Downgrade pyscopg2 to 2.8.6, because 2.9 use datetime.timezone as tz property of datetime object, we do not need pytz._FixedOffset any more See details at [What’s new in psycopg 2.9](https://www.psycopg.org/docs/news.html#what-s-new-in-psycopg-2-9).

based on apache/superset#15768

anggxyz added the #bug Bug report label Jul 18, 2021

zhaoyongjie added need:reproduce and removed #bug Bug report labels Jul 19, 2021

lsyarn added a commit to lsyarn/superset that referenced this issue Sep 26, 2021

fix apache#15768 by use default psycopg2 tzinfo_factory in postgres d…

32a324e

…b engine with psycopg2==2.9.1

likecodingloveproblems referenced this issue Nov 13, 2021

chore: bump py version for integration test (#16213)

4ae88ce

* bump py version for integration test * bump py * bump py * remove files * lock pylint * add not-callable

villebro closed this as completed Jan 28, 2022

nickbp added a commit to scie-nz/walden that referenced this issue Feb 9, 2022

Downgrade psycopg2-binary to 2.8.x to avoid DATETIME column bug

25e12d3

Issue with psycopg2 version workaround: apache/superset#15768 Fixed in (unreleased) Superset: apache/superset#17713

basaravikiran added a commit to basaravikiran/working_superset that referenced this issue Jun 3, 2022

Downgraded psycopg2 version

cb2092e

based on apache/superset#15768

Postgresql DB Engine Error: '>=' not supported between instances of 'datetime.timedelta' and 'int' #15768

Postgresql DB Engine Error: '>=' not supported between instances of 'datetime.timedelta' and 'int' #15768

Comments

anggxyz commented Jul 18, 2021

Expected results

Actual results & Screenshots

How to reproduce the bug

Environment

Checklist

zhaoyongjie commented Jul 19, 2021

srinify commented Jul 19, 2021

wildsonc commented Jul 19, 2021

srinify commented Jul 19, 2021

wildsonc commented Jul 19, 2021

zhaoyongjie commented Jul 20, 2021

wildsonc commented Jul 20, 2021

vijayadeeptim commented Jul 20, 2021

anggxyz commented Jul 20, 2021

anggxyz commented Jul 20, 2021

soitgoes511 commented Jul 25, 2021

soitgoes511 commented Jul 25, 2021 • edited

Ruframapi commented Jul 26, 2021

soitgoes511 commented Jul 26, 2021

amrishparmar commented Aug 6, 2021

mail2lawi commented Aug 12, 2021

jonathanStrange0 commented Aug 20, 2021

dsidlo commented Aug 23, 2021 • edited

dsidlo commented Aug 23, 2021 • edited

santicomp2014 commented Aug 24, 2021 • edited

soitgoes511 commented Aug 25, 2021 • edited

dsidlo commented Aug 26, 2021 • edited

dsidlo commented Aug 28, 2021 • edited

frafra commented Sep 13, 2021

lsyarn commented Sep 26, 2021 • edited

anujpareeksynoriq commented Oct 8, 2021

cclements128 commented Oct 21, 2021

jsanko9 commented Nov 13, 2021

raivtash commented Nov 23, 2021

pvergain commented Dec 6, 2021 • edited

pvergain commented Dec 7, 2021

Before the hack

After the hack

pvergain commented Dec 7, 2021

poxeron commented Dec 9, 2021

ronaldvanrij commented Dec 10, 2021

basaravikiran commented Jan 28, 2022

villebro commented Jan 28, 2022 • edited

soitgoes511 commented Jul 25, 2021 •

edited

dsidlo commented Aug 23, 2021 •

edited

dsidlo commented Aug 23, 2021 •

edited

santicomp2014 commented Aug 24, 2021 •

edited

soitgoes511 commented Aug 25, 2021 •

edited

dsidlo commented Aug 26, 2021 •

edited

dsidlo commented Aug 28, 2021 •

edited

lsyarn commented Sep 26, 2021 •

edited

pvergain commented Dec 6, 2021 •

edited

villebro commented Jan 28, 2022 •

edited