Error with postgres columns of type "TIMESTAMP WITH TIME ZONE"
See original GitHub issue- I have checked the superset logs for python stacktraces and included it here as text if 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
Hey! I’m using SQL Lab with a postgres backend. I can’t select from some tables, specifically when the column has a type of TIMESTAMP WITH TIME ZONE
. An example of the contents of such a cell is 2014-11-24 11:30:02.140381+00
I have other tables with the column of type TIMESTAMP WITHOUT TIME ZONE
, and they work fine. Ex: 2010-01-28T16:59:52.900963
Superset version
0.15.1
Expected results
Query should run and return results.
Actual results
I get flashed a 1 second error message saying “Datatype not understood” which then disappears, and then get shown the loading-spinner.
Stack trace:
2017-01-09 17:09:52,437:INFO:root:Running query:
SELECT product_id,
base_product_id,
updated
FROM public.product_id_mapping LIMIT 100
2017-01-09 17:09:52,513:ERROR:root:data type not understood
Traceback (most recent call last):
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/superset/views.py", line 2500, in sql_json
data = sql_lab.get_sql_results(query_id, return_results=True)
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/celery/local.py", line 188, in __call__
return self._get_current_object()(*a, **kw)
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/celery/app/task.py", line 420, in __call__
return self.run(*args, **kwargs)
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/superset/sql_lab.py", line 171, in get_sql_results
payload['columns'] = cdf.columns_dict if cdf else []
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/superset/dataframe.py", line 54, in columns_dict
agg = agg_func(self.__df.dtypes[col], col)
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/superset/dataframe.py", line 110, in agg_func
if np.issubdtype(dtype, np.number):
File "/Users/user/src/superset/venv/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 755, in issubdtype
return issubclass(dtype(arg1).type, arg2)
TypeError: data type not understood
Steps to reproduce
Run a SELECT query against a postgresql db table that has a column of type TIMEZONE WITH TIME STAMP
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:17 (9 by maintainers)
Top Results From Across the Web
net postgres EF core Cannot write DateTime with Kind=Local ...
InvalidCastException : Cannot write DateTime with Kind=Local to PostgreSQL type 'timestamp with time zone', only UTC is supported.
Read more >Documentation: 15: 8.5. Date/Time Types - PostgreSQL
When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as...
Read more >What is a valid use case for using TIMESTAMP WITHOUT ...
So we would record that in a column of type TIMESTAMP WITH TIME ZONE rather than ... All this type does is make...
Read more >Why does Django create Postgres timestamp columns with ...
The Postgres log shows the update statement that was sent. Django constructed a SQL statement that used UTC as the time zone as...
Read more ><loadData> cannot import columns of type "timestamp with ...
DatabaseException: org.postgresql.util.PSQLException: ERROR: column "published" is of type timestamp with time zone but expression is of ...
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 FreeTop 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
Top GitHub Comments
After poking at this a bit more, it appears the issue is not entirely resolved by updating Pandas. The behavior I’ve observed is as follows:
Prior to updating, an exception would be thrown on any selection from a table containing a
timestamp with time zone
column, regardless of whether or not that column was selected. After updating, it’s possible to select from such a table, as long as the results themselves do not contain anytimestamp with time zone
type values. It does appear to be possible to select atimestamp with time zone
column as long as it’s you cast to atimestamp without time zone
. For example…Applying some function that returns a different type also seems to work fine - converting to date for example:
I’m currently facing the same error, and this is what my requirements.txt looks like:
what are the steps I should take to fix the issues? (really new to this tech stack, hence a noob question)